On Wed, 15 Dec 2010, Thomas Rast wrote: > Martin von Zweigbergk wrote: > > On Tue, Dec 14, 2010 at 1:38 PM, Thomas Rast <trast@xxxxxxxxxxxxxxx> 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 -- 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