On Sun, May 10, 2009 at 10:16 PM, Daniel Pittman <daniel@xxxxxxxxxxxx> wrote:
> The front-end I am using looks for a 'trunk' branch by name in the
> output of 'git branch -a', which historically worked. Now, though, it
> shows that fully qualified.
>
> Looking at the release notes it looks like this was a deliberate change,
> from this entry:
>
> * "git-branch -r" shows HEAD symref that points at a remote branch in
> interest of each tracked remote repository.
>
> However, that isn't unambiguously clear about the change, and is pretty
> light on the "why" parts. Worse, the only discussion I can find about
> the change suggests that this was noticed, and there wasn't real clarity
> about the background.
>
> (See Jeff King under "[PATCH 1/2] add basic branch display tests" at [1]
> for the details.)
>
>
> I confess, to me, that having 'git branch -a' and 'git branch -r' emit
> different values doesn't make much sense, but I suppose the upstream
> code can be adapted.
>
> I wanted to confirm that this was a deliberate change before I went to
> the trouble or rewriting the front-end code however.
Yes, the change was deliberate. Commit 209d336 (builtin-branch:
improve output when displaying remote branches, 2009-02-13) has more
details:
When displaying local and remote branches, prefix the remote branch
names with "remotes/" to make the remote branches clear from the local
branches. If displaying only the remote branches, the prefix is not
shown since it would be redundant.
When you fix your front-end, I suggest you stop parsing git branch's
output. It is a so-called porcelain command, as opposed to a plumbing
command, and so its output is subject to change. You probably want to
use the for-each-ref command instead.
j.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html