Re: [PATCH 2/2] checkout: introduce "--to-branch" option

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Dec 13, 2021, 19:55 UTC
Message-ID: <211213.86r1ag6ztx.gmgdl@evledraar.gmail.com>
In-Reply-To: <xmqqy24pk6f4.fsf@gitster.g>

On Sun, Dec 12 2021, Junio C Hamano wrote:

Show 34 quoted lines

> ZheNing Hu <adlternative@gmail.com> writes:
>
>>> It is unclear if you mean "dev1" exactly point at the commit tagged
>>> as v1.1, or you want the branch "dev1" that is a descedanant of
>>> v1.1.  Without telling that to the reader, the above explanation is
>>> useless.
>>>
>>
>> I meant the former.
>>
>>> And whether you meant the former or the latter, neither use case does
>>> not make much sense.
>>> ...
>>> So, "--to-branch v1.1" that finds and checks out a branch whose tip
>>> exactly points at v1.1 would be pretty useless.
>> ...
>> "git branch --contains v1.1" can find all branches whose history contains the
>>  commit tagged as v1.1. So what if "git checkout --contains v1.1"?
>
> I already said, whether you meant "the only branch that points
> exactly at" or "the only branch that contains", the feature does not
> make sense.  Forcing users to keep only a single branch that either
> points at a given tag is simply impossible and also useless.  Once
> the branch gains even a single commit, it will no loger be pointing
> at the tag, so "let's prepare a branch pointing at v1.1 just in case
> when I want to start working from there" would not be a good
> workflow to begin with.  Forcing users to keep only a single branch
> that contains a given tag would encourage even a worse workflow to
> throw in unrelated things, whose only commonality is that they all
> want to fork from a single tag, into a single branch.
>
> IOW, there is nothing we want to add to "git checkout/switch" for
> this topic.  "git checkout --contains $tag" smells like a solution
> looking for a problem.

I don't see how it's fundimentally different than the DWIM logic of taking "<name>" and seeing that there's only one "refs/heads/<name>", and giving up in other cases where we get ambiguous reference names that we can't resolve.

I.e. I think this is probably useful for some, it's a common workflow to have a 1=1 relationship like this, and if it's 1=many we can just handle it as we do with ambiguous ref, or ambiguous short OIDs for that matter.

But as I noted upthread I really don't see this making sense as a per-command thing, as opposed to some extension of the "peel" syntax. I.e. we should (or at least expose it as such to the user) interpret that sort of argument/newx syntax before "git checkout" et al get to it, so from a UX perspective you could feed a ^{oid2ref} (or whatever it would be called) to rev-parse, checkout etc. etc.