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 <tbsau...@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 f...@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 -- 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
