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

[ZheNing Hu <adlternative@gmail.com>]

Junio C Hamano <gitster@pobox.com> 于2021年12月11日周六 06:14写道：
>
> "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.
>

I meant the former.

> 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.
>

Well, I didn't consider what you said before. I just want to find a shortcut
for "oid -> branches" and "tag -> branches". And I can quickly use it to
switch branches.

> 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.
>

Well, in the case of many branches pointing to one commit, this "--to-branch"
is not very useful.

> 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').
>

"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"?

If there is only one branch, checkout to it; if there are multiple branches,
it will degenerate into "git branch --contains v1.1" to show these branches to
the user. Of course this feature is not very consistent with my
original intention...

> 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.
>
>

Thanks.
--
ZheNing Hu