Re: [PATCH v3] rev-list: refuse --first-parent combined with --bisect

From: Kevin Daudt <me@ikke.info>
Date: Mar 9, 2015, 11:57 UTC
Message-ID: <20150309115733.GB6273@vps892.directvps.nl>
In-Reply-To: <CAPig+cROEyWvJDW7uf1D7owdL-FwLHMtEBwWSNwS1M=vMcozLQ@mail.gmail.com>

On Sun, Mar 08, 2015 at 05:58:24PM -0400, Eric Sunshine wrote:

Show 11 quoted lines

> On Sun, Mar 8, 2015 at 11:03 AM, Kevin Daudt <me@ikke.info> wrote:
> > rev-list --bisect is used by git bisect, but never together with
> > --first-parent. Because rev-list --bisect together with --first-parent
> > is not handled currently, and even leads to segfaults, refuse to use
> > both options together.
> >
> > Signed-off-by: Kevin Daudt <me@ikke.info>
> > Suggested-by: Junio C. Hamano <gitster@pobox.com>
> 
> It's customary for your sign-off to be last.
>

Ok, noted

Show 17 quoted lines

> > ---
> > diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
> > index 4ed8587..05c3f6d 100644
> > --- a/Documentation/rev-list-options.txt
> > +++ b/Documentation/rev-list-options.txt
> > @@ -123,7 +123,8 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit).
> >         because merges into a topic branch tend to be only about
> >         adjusting to updated upstream from time to time, and
> >         this option allows you to ignore the individual commits
> > -       brought in to your history by such a merge.
> > +       brought in to your history by such a merge. Cannot be
> > +       combined with --bisect.
> 
> A couple questions:
> 
> Should the documentation for ---bisect be updated to mention this
> restriction also?

Was doubting whether that was necessary as --bisect can be seen as a mode, and --first-parent modifying that mode. But it can make sense to also add it to that section.

> 
> Should this change be protected by a "ifndef::git-rev-list[]" as are
> all other mentions of "bisect" in rev-list-options.txt?

Yes, I see why. git log also uses rev-list-options.txt and it has a --bisect option that is unrelated to this one, so that comment doesn't make sense for git log.

Will reroll this later.