spdr870/gitextensions — pull request #1114 by vcpp (2012-07-12 21:03:37+00:00)
Title: Do not display remote HEAD as a remote branch

This change may need some discussion.

I've just noticed that remote HEAD seems to be redundant in revisions graph, because there is always at least one another remote branch (usually, origin/master).

What about hiding remote HEAD?

Pros:
0. Users are confused to see that “fake” branch at first time (“what is that?”), then they get accustomed to ignore it (“ah, I never touched that, it's some system thing”).
1. When user wants to rebase or merge with default remote branch, there are at least two options in context menu: “origin/HEAD” and “origin/master”, so from time to time I receive questions like “how to make decision of head vs master” or “which option is more correct”.
2. Even if you know that there is no difference from DAG point of view, you still need one extra click and your repo will contain both kind of commit messages “Merge (...) 'origin/master' into X” and “Merge (...) 'origin/HEAD' into X”.

Cons:
0. Detached HEAD. I've never seen detached head on a bare server repo, but it should be possible. You can also add your teammate's repo as remote where detached head is more likely exist during some operations like rebase. I don't know if someone really needs to use remote repo's detached head.
1. Less info. When you see “origin/somebranch” and “origin/HEAD” at one line, you know that somebranch is default for that remote. When there are few remote branches point to the same commit, you know that one of them is default. This affects remote cloning, but does it matter later?

Current change is as simple as possible. To satisfy both cons, we could also read head file content and show head if it points directly to some commit or hide head itself and mark remote branch as default if head points to branch.