Git branches left after pr

The wiki is the first repo I have had admin privileges with and dealing with an outside pr.

I noticed that after a recent contribution was accepted and merged, when I did a fetch, their patch branch was fetched and added to the remotes.

$ git branch -r
  origin/HEAD -> origin/master

This branch is not listed when using the web interface so I started digging around and found this under the repo was not toggled.

Does the engine repo have this toggled?

Should I just delete this branch?

If your talking about this line:

And you are running the command line on your personal machine, (As you appear to be) this refers to your local list of remotes.

At some point, you:

  • added their repo to your remotes
  • fetched from it
  • checked out/created a local tracking branch

(Probably while reviewing the changes before accepting them)

These steps may have been done in shorthand. (git has a lot of command -<flag> <arguments> variants that are equivalent to running two or more simpler commands in sequence) They may even have been done automatically by a GUI tool.

This has nothing to do with references/branches being kept in the main repository. If the work on these changes is done, you can safely delete that branch from your local repository, and probably also delete their repo from your remotes. (if you expect more contributions from the same person in the future, I’d leave the remote. You’ll be fetching another set of changes from them soon enough.)

Thanks for reply. This is not the case though. We had a pr submitted from a fork of the wiki repo that was merged via the github web interface.

Later, I was doing some other things via the web interface so I did a fetch and this patch branch showed up in my remotes in addition to what I was looking for.

So this means that after the pr merge into master, that patch branch from the pr was not deleted.

This is why I asked the question if that setting from the github docs link was being used in the jmonkeyengine repo or am I supposed to manually delete these patch branches after we merge pr’s from forks.

Edit: I ran prune so that branch is on the repo site still.

Edit2: I would expect this branch to go away if the person submitting the pr deletes the branch since the pr was merged, but what if they dont? We could potentially have these branches lying around after every fork/pr/merge.

If you have privileges, it’s not too difficult to delete a remote branch using Git:

version control - How do I delete a Git branch locally and remotely? - Stack Overflow

Heh, I guess this is going over everyone’s head.

Its about management of the repo.

When the engine gets a pr from a fork and it gets merged into master, do you guys manually delete all these leftover patch branches if the submitter does not delete the branch themselves or do you use the settings toggle shown in the docs?

I know I can delete them manually. With the engine having literally hundreds of pr merges from forks I would be very afraid of doing a fetch if some sort of house keeping isn’t done there.

1 Like

Ah. Well, I know I’ve deleted branches in the past after closing a PR. So I’ve done some housekeeping, I guess. It never seemed like a major concern though.

The official “jmonkeyengine” repo has 16 non-release branches, most of which date from before my time. Since I don’t know whether the “monkanim” branch (say) might prove useful in the future, I haven’t deleted it.

When I clone “jmonkeyengine” I always specify which branch or branches I’m interested in, so I never fetch all 21.

This, however, is not a jme repo branch.

The kaenganxt prefix is explicitly pointing to the contributor’s GitHub account. (They seem to have completely taken down the fork. Perhaps some weirdness ensued if they did this before the PR was resolved?)

The branch is certainly not present on a fresh clone of the wiki as of five minutes ago…

What is the result of git remote -v?

Yes, its there.

$ git remote -v
kaenganxt (fetch)
kaenganxt (push)
mitm-wiki (fetch)
mitm-wiki (push)
origin (fetch)
origin (push)

Fetch must of set that up. I deleted that remote and pruned.

This was first time I used fetch after a merge from an forked pr like that. When I am contributing to other repos using a fork, I always delete the branch myself after the merge and had no idea the branch could just hang around in the repo if I didn’t.

Thats why I was asking about the setting that can be toggled to auto delete branches after merge. I am unsure if that’s the intended use for that setting under the settings tab.

And that shouldn’t have pulled in this branch, as this branch never was part of the jme repo.

You didn’t happen to use git fetch -all, did you? If so, that implies that you had the kaenganxt url in your remotes already, perhaps from previous interactions, even if you didn’t have any branches tied to that repo.

I ran git fetch as best I can remember. That remote wasn’t there prior.

I had actually just completed a git cherry-pick from my independent repo of the wiki so I know it wasn’t in the remotes prior to fetch as I had just listed and used my remotes.

I pushed those cherry-picked commits.

You can see that I fixed an bug (ed7c69f) in the workflow, merged his pr (24957ef) then I fetched.