Re: 'HEAD' is not a commit (according to git-checkout)

From: Junio C Hamano <gitster@pobox.com>
Date: May 24, 2020, 16:15 UTC
Message-ID: <xmqqimglqpga.fsf@gitster.c.googlers.com>
In-Reply-To: <ad267e83-eea0-bb78-d88c-a37a28d04dbe@web.de>

René Scharfe <l.s.r@web.de> writes:

Show 6 quoted lines

> OK, but stepping back a bit and trying to forget what I know about the
> option --track and pretending to see it for the first time, I have to
> ask: Why doesn't it take an argument?  If I check out a raw commit, it
> cannot guess the upstream branch anyway.  So I'd assume this to work:
>
>    git checkout -b new-branch --track=upstream start-point

Assuming that --track option is marked with PARSE_OPT_OPTARG and when the option is given, we internally do a rev-parse of both upstream and start-point and make sure the tip of the "track" is an ancestor of the "start-point", I think it makes sense. That would catch cases like this:

	git checkout --detach origin/master
	... work work work ...
	git checkout -b new-branch --track=origin/master HEAD

On the other hand, some use case might want to go the other way, e.g.

	git checkout --detach origin/master~12
	... work to fix an older bug ...
	git checkout -b new-branch --track=origin/master HEAD

in which case the start-point and the current tip of the tracking branch has no relation other than they share a common ancestor.

So, should we allow a random upstream & start-point combination? It appears to me that as long as they share _some_ common ancestory, it may make sense.