From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-6.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 0CC061FEB3 for ; Fri, 13 Jan 2017 01:39:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750951AbdAMBjJ (ORCPT ); Thu, 12 Jan 2017 20:39:09 -0500 Received: from mout02.posteo.de ([185.67.36.66]:54500 "EHLO mout02.posteo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750890AbdAMBjJ (ORCPT ); Thu, 12 Jan 2017 20:39:09 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 530F320C55 for ; Fri, 13 Jan 2017 02:39:06 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3v04zY4vpszyrx; Fri, 13 Jan 2017 02:39:05 +0100 (CET) From: Manuel Ullmann To: Christian Couder Cc: Junio C Hamano , git Subject: Re: Bug report: Documentation error in git-bisect man description References: <87r347swz1.fsf@sonnengebleicht.fritz.box> Date: Fri, 13 Jan 2017 02:39:05 +0100 In-Reply-To: (Christian Couder's message of "Fri, 13 Jan 2017 02:13:15 +0100") Message-ID: <871sw7u4au.fsf@sonnengebleicht.fritz.box> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org > On Fri, Jan 13, 2017 at 12:42 AM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> Manuel Ullmann writes: >>> >>> Hmmm, I tend to agree, modulo a minor fix. >>> >>> If the description were in a context inside a paragraph like this: >>> >>> When you want to tell 'git bisect' that a belongs to >>> the newer half of the history, you say >>> >>> git bisect (bad|new) [] >>> >>> On the other hand, when you want to tell 'git bisect' that a >>> belongs to the older half of the history, you can say >>> >>> git bisect (good|old) [] >>> >>> then the pairing we see in the current text makes quite a lot of >>> sense. >> >> Actually, the above is _exactly_ what was intended. I misread the >> current documentation when I made the comment, and I think that the >> current one _IS_ correct. The latter half of the above is not about >> a single rev. You can paint multiple commits with the "older half" >> color, i.e. >> >> On the other hand, when you want to tell 'git bisect' that >> one or more s belong to the older half of the history, >> you can say >> >> git bisect (good|old) [...] >> >> In contrast, you can mark only one as newer (or "already >> bad"). So pairing (bad|good) and (new|old) like you suggested >> breaks the correctness of the command line description. > > Yeah, I agree. > >> If (bad|new) and (good|old) bothers you because they may mislead the >> readers to think bad is an opposite of new (and good is an opposite >> of old), the only solution I can think of to that problem is to >> expand these two lines into four and list them like this: >> >> git bisect bad [] >> git bisect good [...] >> git bisect new [] >> git bisect old [...] > > Maybe it would be more complete and a bit clearer if it was: > > git bisect (bad|new|) [] > git bisect (good|old|) [...] That would clarify the intention quite a bit (at least for me). Best regards, Manuel