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