On Tue, Mar 10, 2015 at 03:09:54PM -0700, Junio C Hamano wrote:
> Kevin Daudt <m...@ikke.info> writes:
> 
> > 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.
> >
> > Suggested-by: Junio C. Hamano <gits...@pobox.com>
> > Helped-by: Eric Sunshine <sunsh...@sunshineco.com>
> > Signed-off-by: Kevin Daudt <m...@ikke.info>
> > ---
> > Changes since v3:
> >
> > * Added an ifdef::git-rev-list[] guard around the warning in the
> >   --first-parent section so that it only shows up in `man git-rev-list`
> >   and not in `man git log`
> >
> > * Added the warning also to the --bisect section.
> 
> I wonder what "git log --first-parent --bisect A..B" should do,
> though.
> 
> Wouldn't the rejection belong to revision.c::setup_revisions(),
> where we reject combined use of (--reverse, --walk-reflogs) and
> (--children, --parents), to apply this to all commands in the "log"
> family that uses the revision walker machinery?
> 

git log --bisect seems to do something different then git rev-list
--bisect

>From git-log(1):

    Pretend as if the bad bisection ref refs/bisect/bad was listed and
    as if it was followed by --not and the good bisection refs
    refs/bisect/good-* on the command line.

This seems to just add addition refs to the log command, which seems
unrelated to what rev-list --bisect does.

So I don't see why git log --bisect --first-parent should be prohibited
(unless this combination doesn't make sense on itself).

Kevin.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to