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.
