Re: PATCH: improve git switch documentation

> On 13/07/2021 00:12, Felipe Contreras wrote:
> > Martin wrote:
> > A user that does:
> > 
> >    git switch -n <branch>
> > 
> > Would naturally expect a new branch to be created.
> > 
> > If that command creates a new branch safely, why would the user do:
> > 
> >    git switch -N <branch>
> > 
> > What do you think the user expects to happen without reading the
> > documenation?
> 
> Well, first of all what would he think it does if he reads the doc? And 
> if that doc looses no (explicit) word on the possible loss?
> 
> First of all (not sure, if I mentioned that before), I have seen *many* 
> case like that:
> The user wants to create a new branch on master "my-feature".
>     git switch -c my-feature
> Then he realizes that he had not been on master, but on some other 
> branch. "-c" now gives an error.
> So the  user reads the documentation.
> Up to this point, everything is exactly as it should be.
> Now what the user reads is that "-C" works if the branch already exists. 
> At this point, without being prompted those user will not think of any 
> content of the branch (they haven't even added some).
> "-C" does in that case what they want.
> 
> Of course now, that they had no need to think about any commits, an no 
> warning that would have prompted that, they believe "-C" to be save.

> > And what do you think they'll expect to happen given this documentation:
> > 
> >    Create a new branch like '--new', but if the branch already exists
> >    it's replaced.
> > 
> > Forget about what they could misunderstand. Nobody does anything without
> > a reason, so what would be the reason why a user does `git switch -N`
> > instead of `git switch -n`?
> 
> You and I will make the connection between "something happens to the 
> branch" and "something happens to the commits".
> A lot of people with less experience, who a busy looking through lots of 
> stuff to solve their problem, they will not make that connection in that 
> particular moment.
> Heck, I've seen highly educated people missing far more obvious things 
> like that.

> > To me this is another instance of "do not drink scorching hot coffee".
> > Sure, some users might benefit from reading this, but how many? And how
> > many would be annoyed by the obvious unnecessary warning?
> 
> Well, at least in the U.S, you apparently have to tell your customers 
> that the coffee you sell is hot. (If you recall, there was a "famous" 
> court case).

> > Moreover, most users don't even read the documentation. Some might even
> > be doing `git switch -h`, and others using zsh completion description.
> > So we can't just rely on them reading this line.
> 
> Well, so we can't warn the rest? Why do we have docs at all?

> > If you are really worried about the user losing information, why don't
> > we add a true warning:
> > 
> >    hint: The previous state of the '%s' branch might have been lost.
> >    hint: The id was '%s'.
> >    hint:
> >    hint: If you didn't intend to do this, you can restore the previous
> >    hint: state with:
> >    hint:
> >    hint:  git reset --hard @{1}
> >    hint:
> >    hint: Disable this message with "git config advice.switchForceNew false"
> > 
> > That way the user doesn't need to read the documentation.
> 
> Well yes, printing a recovery note, may be another helpful addition.
> 
> But as you said, a single way of pushing info, will not reach everyone.