Martin <git@xxxxxxxxxx> 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.
