Re: PATCH: improve git switch documentation

[Martin <git@mfriebe.de>]

On 01/07/2021 16:58, Junio C Hamano wrote:
> 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:
> 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".


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


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