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

[Junio C Hamano <gitster@pobox.com>]

"ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: ZheNing Hu <adlternative@gmail.com>
>
> When we want checkout to a branch (e.g. dev1) which reference
> to a commit, but sometimes we only remember the tag (e.g. v1.1)
> on it, we will use `git checkout v1.1` to find the commit first,
> git will be in the state of deatching HEAD, so we have to search the
> branches on the commit and checkout the branch we perfer. This will
> be a bit cumbersome.
>
> Introduce "--to-branch" option, `git checkout --to-branch <tag>`
> and `git checkout --to-branch <commit>` will search all branches
> and find a unique branch reference to the commit (or the commit which
> the tag reference to) and checkout to it. If the commit have more
> than one branches, it will report error "here are more than one
> branch on commit".

Sorry, but the above explanation does not make any sense to me.  

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.

And whether you meant the former or the latter, neither use case does
not make much sense.

First, suppose you meant "checkout --to-branch v1.1" to find a
branch whose tip exactly points at v1.1.  You instead check out
"dev1" branch, and work on it to advance its history.  When you are
done, you may go to another branch and work on something else.

But then what?  When you need another topic that also needs to be
later merge-able to v1.1, "checkout --to-branch v1.1" no longer will
be able to find "dev1", because, well, you have already used it to
build something else.

So, "--to-branch v1.1" that finds and checks out a branch whose tip
exactly points at v1.1 would be pretty useless.

So let's correct the unwritten assumption and say "--to-branch v1.1"
finds a branch that is descendant of the tag.  It is like I have
maint-2.33 branch to prepare for v2.33.1, v2.33.2,... maintenance
releases and being able to find maint-2.33 by saying v2.33.2 (or
v2.33.1) _might_ be convenient.

But that would only be true if there is only one single branch per
family of tags (in the above example, v2.33.* tags).  You cannot use
the workflow where many topic branches run in parallel, and get
merged to the integration branch(es) only after they are ready,
because you need bugfix-1-for-v2.33, bugfix-2-for-v2.33,... branches
all forked from v2.33.0 (or a commit with a later tag in the v2.33.*
family) to cook these independent fixes that are destined for the
maint-2.33 integration branch, so you cannot uniquely find maint-2.33
by saying v2.33.0 or v2.33.1 or whatever.

I also sense that the first paragraph of the proposed log message
for this commit hints that the user needs a bit more studying of
existing tools.  When we know v1.1 but do not know if we already
have branches that are based on it, we DO NOT do "git checkout v1.1".
Instead the first thing we would do is "git branch --contains v1.1"
(add "--no-merged main" to exclude the branches that have already
graduated to 'main').

So, for this partcular topic, what I would recommend is *not* jump
in and add a new feature, but to study what's available and build a
workflow around the existing features.