Re: PATCH: improve git switch documentation
- From
- Martin <git@mfriebe.de>
- Date
- Jul 1, 2021, 17:29 UTC
- Message-ID
- <167b8fe6-0586-b980-dfb9-9fa3a29d48bb@mfriebe.de>
- In-Reply-To
- <xmqqh7hersgp.fsf@gitster.g>
On 01/07/2021 16:58, Junio C Hamano wrote:
Show 9 quoted lines
> If I understand you correctly, the confusion your hypothetical > newbie would have is caused by the word "start-point" in > > git branch -f <branch-name> <start-point> > > That is, if we repoint the branch that is currently at Z to point at > X with "git branch -f B X", it is possible to imagine that we build > more history on top of "X" simply because "X" is called "start-point", > i.e. we start at X and do something more.
It is probably more the use of the word "branch" than it is "start point"
Sergey made an excellent point:
Show 8 quoted lines
> On 01/07/2021 13:27, Sergey Organov wrote: >> For example: >> >> "branch": a chain of commits >> >> "branch tip": the most recent commit in a branch >> >> "branch name": specific type of symbolic reference pointing to a branch tip
A lot of people think of the "chain of commits" when the word "branch" is used.
If we take the sentence from the current doc: --force-create Similar to |--create| except that if |<new-branch>| already exists, it will be reset to |<start-point>| and replace "branch" with "chain of commits" Similar to |--create| except that if |<new-||"chain of commits">| already exists, it will be reset to |<start-point>|
What would you expect to happen? I would think the "chain of commits" is created at the new <start-point>
What we want to say is The "branch name" will point to a new "branch tip" at <start-point>
However, this still leaves the point, that new users need to understand certain concepts and implications. Such as moving a "branch name" abandons the old "chain of commits" (they do not follow). "branch name" helps to remember that distinction, but it still needs to be learned first. "abandon" => leave them to the reflog until expiry.
The point is, that those concepts (difference between branchname, and commits in branch) may all be documented. But the reader may still be learning all this. Then it will certainly help new users to learn , if the consequences of those are mentioned in places like "switch -C".
Show 5 quoted lines
> But I find two problems with the proposed solution to solve that > confusion. > * In general, when an explanation in the documentation says that > a command does A, it shouldn't have to say "the command does A > but does not do B or C on top of that".
Ok, that make sense. In general "negative" statements are not helpful.
> I think the source of the confusion is the <start point>. It does > not change what the explanation wants to say at all if we changed > it to <end point>.
I don't actually see <start point> as the issue. But if it was then <end point> would mean that your existing "chain of commits" would end there (as if it was a merge).
> It is where the branch's tip ends up to be after > "git branch -f" (or "git switch -C") finishes, so it might even be > technically more correct.
But it is also where new commits for that branch will start. (they start at the current end, but that is confusing...) Thinking about the name <fork point> would be more meaningful?
IMHO, start is way better than end. But "fork" is good too.
While going through the patch, I just noted
"git branch" uses <branchname> "git switch" uses <new-branch>
It would be (a tiny) improvement, if "git switch" also used <branchname> 1) it does help to get away from "chain of commits" 2) in case of -C the "new" part is actually wrong.
Using <commit> instead of <start-point> is better too. Not so much for the above reasons. <start-point> described the function. But it did not tell you that you need a <commit> Now you know you need a <commit>, and then you can check the function from the doc.
Show 10 quoted lines
> ------------ > @@ -70,7 +70,7 @@ $ git switch <new-branch> > -C <new-branch>:: > --force-create <new-branch>:: > Similar to `--create` except that if `<new-branch>` already > - exists, it will be reset to `<start-point>`. This is a > + exists, it will be reset to `<commit>`. This is a > convenient shortcut for: > + > ------------
Now with <branchname> that would be
--force-create <new-branch>:: Similar to `--create` except that if `<branchname>` already exists, it will be reset to [point to] `<commit>`. This is a convenient shortcut for:
At least, there would no longer be a word, that can be read as "chain of commits" So <branchname> would be a definite improvement too.
Not sure if [point to] should be inserted?
I would still think, users should be somehow reminded of the implicit consequences. Users reading that part of the doc may still be in the progress of learning all the concepts. If nothing else, then maybe The branch previously at [pointed to by] <branchname> will/may no longer be reachable. That is, it is obviously no longer reachable by <branchname>. But it may not be reachable by anything else either (reflog excluded).
However, adding any such "reminder" may be part of a more general discussion how verbose the documentation should be. I.e. as you wrote in an earlier email, why for "switch" but not for others. The argument that "switch" is one of the more essential commands, may not be enough.