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.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 5A21B1F8C6 for ; Tue, 6 Jul 2021 22:26:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229891AbhGFW3C convert rfc822-to-8bit (ORCPT ); Tue, 6 Jul 2021 18:29:02 -0400 Received: from elephants.elehost.com ([216.66.27.132]:38249 "EHLO elephants.elehost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229781AbhGFW3C (ORCPT ); Tue, 6 Jul 2021 18:29:02 -0400 X-Virus-Scanned: amavisd-new at elehost.com Received: from gnash (cpe00fc8d49d843-cm00fc8d49d840.cpe.net.cable.rogers.com [173.33.197.34]) (authenticated bits=0) by elephants.elehost.com (8.15.2/8.15.2) with ESMTPSA id 166MQJ2h057390 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Jul 2021 18:26:20 -0400 (EDT) (envelope-from rsbecker@nexbridge.com) From: "Randall S. Becker" To: "'Junio C Hamano'" Cc: "'Felipe Contreras'" , "=?utf-8?Q?'=C3=86var_Arnfj=C3=B6r=C3=B0_Bjarmason'?=" , , "'Alex Henrie'" , "'Richard Hansen'" References: <20210705123209.1808663-1-felipe.contreras@gmail.com> <20210705123209.1808663-2-felipe.contreras@gmail.com> <87bl7f5ho1.fsf@evledraar.gmail.com> <60e4bf9a6a628_1c4281208b@natae.notmuch> <04de01d772a8$540c6690$fc2533b0$@nexbridge.com> <04e001d772ae$3d87e0b0$b897a210$@nexbridge.com> In-Reply-To: Subject: RE: [RFC PATCH 01/35] merge: improve fatal fast-forward message Date: Tue, 6 Jul 2021 18:26:14 -0400 Message-ID: <04e201d772b5$f1812a20$d4837e60$@nexbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT X-Mailer: Microsoft Outlook 16.0 Content-Language: en-ca Thread-Index: AQEjwC2BG0r8Ti4tiVL2ONsdEMpHYQJC7SfhAdO76CQCFHAokgHyNSSTA1ClLhUClPLnigI7dTtDrBv4YsA= Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On July 6, 2021 5:54 PM Junio C Hamano wrote: >"Randall S. Becker" writes: > >> On July 6, 2021 4:56 PM, Junio C Hamano wrote: >>>"Randall S. Becker" writes: >>> >>>>>If you do: >>>>> >>>>> % git merge --ff-only >>>>> fatal: Not possible to fast-forward, aborting. >>>>> >>>>>That "aborting" part is redundant; we know `git merge` should abort >>>> if the fast-forward is not possible, we explicitely told git to do >>>> that. >>>> >>>> `git merge` is a special operation where errors (conflicts, for one) >>>> may leave the repository in a merge pending state where you >>>> subsequently may have to use `git merge --abort` to reset the >>>> situation or `git add` to continue. The `aborting` output makes it >>>> clear that you do not have to do the `--abort` and *cannot* do the >>>> `add` because there was an implicit `--abort` done resulting from >>>> the failure. This is important information for the user. >>> >>>If so, adding ", aborting" to the end is misleading. In this >>>particular failure mode, the command pretends that the merge did not even start. >> >> You know that, and I know that. I contend that git users do not >> generally want to care about failure modes. While a flow description >> might be instructive, I doubt many git users would look at it. We can >> only hope that front ends know how to make this clean for them. > >They may not care about "failure modes" but they would want to know that in this situation, unlike other times, they do not have to say >"git merge --abort" (or "git reset --hard"). Saying ", aborting" >does not help as much as saying say ", not starting a merge", for example. I like that a lot, actually "not starting a merge" is much more helpful.