Re: [PATCH] branch: do not attempt to track HEAD implicitly

[Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>]

On Wed, 15 Dec 2010, Thomas Rast wrote:

> Martin von Zweigbergk wrote:
> > On Tue, Dec 14, 2010 at 1:38 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> > > Silently drop the HEAD candidate in the implicit (i.e. without -t
> > > flag) case, so that the branch starts out without an upstream.
> > 
> > Thanks. This has been on my todo list for a while.
> > 
> > Should it only check for HEAD? How about ORIG_HEAD and FETCH_HEAD?
> > Simply anything outside of refs/ maybe? Would that make sense?
> 
> Good point.  It seems HEAD wins the dwim_ref() over the rest:
> 
> $ g rev-parse HEAD ORIG_HEAD FETCH_HEAD
> 79f9a226d33659f0e6a69429931d66b5f70c9708
> 79f9a226d33659f0e6a69429931d66b5f70c9708
> 79f9a226d33659f0e6a69429931d66b5f70c9708

Probably a stupid question, but why are all three of them pointing to
the same commit? I guess that is what you want to show, but how did
you get there? If I run the same command (I assume your 'g' alias
simply calls git), I get three different commits (in general, of
course).

> $ g branch test
> $ g config -l | grep branch.test.
> 
> Not sure through which mechanism, however.

The scenario I meant is the following:

$ git config branch.autosetupmerge always
$ git branch test ORIG_HEAD
Branch test set up to track local ref ORIG_HEAD.
$ git config -l | grep branch.test
branch.test.remote=.
branch.test.merge=ORIG_HEAD


/Martin