From: Trevor Saunders <tbsaunde@tbsaunde.org>
Date: Sun, 10 May 2015 23:12:45 GMT
Subject: Re: [PATCH] bisect: print abbrev sha1 for first bad commit
Message-ID: <20150510231110.GA25157@tsaunders-iceball.corp.tor1.mozilla.com>
In-Reply-To: <20150509040704.GA31428@peff.net>

On Sat, May 09, 2015 at 12:07:04AM -0400, Jeff King wrote:
> On Fri, May 08, 2015 at 10:03:41PM -0400, Trevor Saunders wrote:
> 
> > On Fri, May 08, 2015 at 05:29:42PM -0700, Stefan Beller wrote:
> > > On Fri, May 8, 2015 at 4:46 PM, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
> > > > its rather silly especially considering the next line contains the
> > > > full hash again.
> > > 
> > > Maybe we can omit it altogether then?
> > 
> > SO we'd print something like
> > 
> > the first bad commit is
> > Commit abcdefabcdefabcdefabcdefabcdefabcdefabcd
> > Author foo@ba.com
> > 
> > blah blah blah
> > 
> > ? That seems reasonable to me.  If we're going that far does it also
> > make sense to drop printingthe lines about which trees have changed and
> > just print the commit message / author / hash?
> 
> Yeah, I have always found bisect's output somewhat silly. It prints the
> "--raw" diff output, which is not incredibly useful. And then to top it
> off, it does not feed the "--recursive" switch to the diff, so you don't
> even get to see the real list of changed files.

 So, fun fact it doesn't actually always print the raw diffoutput if
 there is no diff, for example a merge where both sides only touched
 different files as in test 40 in t6030.

> (Actually, it looks like all this is generated in bisect.c:show_diff_tree,
> so it would have to be written in C; but it should be pretty easy to
> tweak the display options).

yeah, that seems pretty straight forward, but I'm not really sure what
to do about this case where no diff is printed, I guess I should figure
out what bits need to be set for the commit to be shown anyway.

Trev