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.
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.
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.
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…
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.