Re: [PATCH] bisect: print abbrev sha1 for first bad commit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 11, 2015 at 6:54 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Christian Couder <christian.couder@xxxxxxxxx> writes:
>
>> On Mon, May 11, 2015 at 6:33 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>> Jeff King <peff@xxxxxxxx> writes:
>>>
>>>> I'd argue for simply never showing the diff (dropping the "opt.diff = 1"
>>>> line from bisect.c:show_diff_tree), but that is mostly my personal
>>>> opinion.
>>>
>>> Yeah, I think that is sensible. It may even be OK to just give a
>>> "log --oneline".
>>
>> Or maybe we could let the user configure the diff options or even the
>> command used when the first bad commit is found?
>
> That is a separate discussion.  I do not mind but I doubt many
> people would use it (I was tempted to say "doubt anybody would", but
> then was reminded how many people use Git, and toned it down), as
> long as we have a good default.  And I thought that this discussion
> was about coming up with a good-enough default.
>
> To be bluntly honest, I think the current one is sufficient as a
> good-enough default.  The first thing I would do after seeing that
> message is to either "git checkout <commit-object-name>" or "git
> show <commit-object-name>", and the current full 40-hex output gives
> me an easier mouse-double-click target than the proposed abbreviated
> one, so in that sense the original proposal may even be a usability
> regression.

Yeah, it might also be a regression if some users have scripts that
depend on the current behavior. That's why with a config option,
people annoyed by the current behavior can get exactly what they want,
and it makes it possible to more safely change the default to
something more user friendly the next time we change the major version
number.

> It is tempting to say that the output can be eliminated by always
> checking out the first-bad-commit (i.e. only when the last answer
> that led to the first-bad decision was "good", do a "git checkout"
> of that bad commit), but in a project where a branch switching is
> not instantaneous, that might be problematic (unless the first step
> the user would have done is to check it out anyway, of course).

Yeah, and speaking of regressions, elimiting the output might be a
more serious regression.

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]