Subject: Re: PATCH: improve git switch documentation

From: Junio C Hamano <[email-masked]>
Date: Tue, 29 Jun 2021 15:39:21 -0700

Martin <[email-masked]> writes:

> My text may indeed have lacked clarity. I was trying to emphasize to
> hard, that this
> command's "force" enables 2 actions that may both not be
> wanted. Usually if one applies
> "force" to a command only one such action is expected, or at least I
> would only expect the one.

Oh, I do agree wholeheartedly if two things are forced at the same
time, things can become confusing.

But the thing is, there are no such "two things are forced at once"
in this case.  That is why I emphasized, in my response to you, that
"switch -C <newbranch>" does not touch working tree, so "ok, the
switch stops because it requires some working tree files with
changes clobbered, and I can force it to make it happen" is not
involved.  If it were, then it becomes fuzzy if --force is allowing
an existing branch getting overwritten, or allowing a modification
in a working tree file getting discarded, or both.

The one and only thing that is forced is to repoint the tip of an
existing branch.

> The actions being, giving up the link to the commit that is the tip of
> the branch; and
> making commits unreachable.  (for an expert in git tightly linked
> together, but not for everyone)

Sorry, I do not quite see how the removing the reference to a commit
(i.e. the commit C that used to be pointed at by the branch would no
longer be pointed at by that branch---that is by definition what
moving the branch to point at a different commit means) and the
commit becoming not reachable from the reference (i.e. such a commit
C may not be reachable from the branch---unless the new commit it
points at happens to be a descendant of C) are not one and the same
thing.  I do not think there is distinction between expert vs
everyone else involved here at all.

Can you give an example where one of the two holds while the other
one does not?

Thanks.