From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.0 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 373191F8C6 for ; Thu, 1 Jul 2021 17:29:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233207AbhGARbl (ORCPT ); Thu, 1 Jul 2021 13:31:41 -0400 Received: from smtprelay08.ispgateway.de ([134.119.228.110]:20508 "EHLO smtprelay08.ispgateway.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233239AbhGARbl (ORCPT ); Thu, 1 Jul 2021 13:31:41 -0400 Received: from [84.163.72.76] (helo=[192.168.2.202]) by smtprelay08.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lz0Ud-0007wx-FC; Thu, 01 Jul 2021 19:28:51 +0200 From: Martin Subject: Re: PATCH: improve git switch documentation To: Junio C Hamano Cc: git@vger.kernel.org References: <7870a0ad-8fa1-9dbd-1978-1f44ec6970c5@mfriebe.de> Message-ID: <167b8fe6-0586-b980-dfb9-9fa3a29d48bb@mfriebe.de> Date: Thu, 1 Jul 2021 19:29:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Df-Sender: bWVAbWZyaWViZS5kZQ== Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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 > > 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 || already exists, it will be reset to || and replace "branch" with "chain of commits"     Similar to |--create| except that if || already exists, it will be reset to || What would you expect to happen? I would think the "chain of commits" is created at the new What we want to say is     The "branch name" will point to a new "branch tip" at 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 . It does > not change what the explanation wants to say at all if we changed > it to . I don't actually see as the issue. But if it was then 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 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 "git switch" uses It would be (a tiny) improvement, if "git switch" also used 1)  it does help to get away from  "chain of commits" 2)  in case of -C the "new" part is actually wrong. Using instead of is better too. Not so much for the above reasons.   described the function. But it did not tell you that you need a Now you know you need a , and then you can check the function from the doc. > ------------ > @@ -70,7 +70,7 @@ $ git switch > -C :: > --force-create :: > Similar to `--create` except that if `` already > - exists, it will be reset to ``. This is a > + exists, it will be reset to ``. This is a > convenient shortcut for: > + > ------------ Now with that would be --force-create :: Similar to `--create` except that if `` already exists, it will be reset to [point to] ``. This is a convenient shortcut for: At least, there would no longer be a word, that can be read as "chain of commits" So 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] will/may no longer be reachable. That is, it is obviously no longer reachable by . 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.