Junio C Hamano <gitster@xxxxxxxxx> 于2021年12月11日周六 06:14写道： > > "ZheNing Hu via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: ZheNing Hu <adlternative@xxxxxxxxx> > > > > 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
