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

From: Stefan Beller <sbeller@google.com>
Date: May 12, 2015, 20:58 UTC
Message-ID: <CAGZ79kZG=9BkEGB_GOsg7F-2mN5iTjmTFK+vUohj_7wJLfPtig@mail.gmail.com>
In-Reply-To: <CAP8UFD0k-=ESEu-7jhf8Y5wz+5A=MHsjtMnC7YJv_DRi30TmDw@mail.gmail.com>

On Tue, May 12, 2015 at 1:43 PM, Christian Couder <christian.couder@gmail.com> wrote:

Show 47 quoted lines

> On Tue, May 12, 2015 at 7:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Christian Couder <christian.couder@gmail.com> writes:
>>
>>> On Mon, May 11, 2015 at 6:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>>> 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.
>>> ...
>>>> 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.
>>
>> I am getting somewhat annoyed by this line of thought.
>>
>> Who said bisect output is meant to be parseable and be read by
>> scripts in the first place?  If that were the case, we wouldn't be
>> having this discussion thread in the first place.
>
> Well "git bisect run" is all about automating bisecting and we know
> that some people have been using it for a long time.
>
> See for example this message from 2007:
>
> http://lkml.iu.edu/hypermail/linux/kernel/0711.1/1443.html
>
> where there is:
>
> "Today we can autonomouly
> bisect build bugs via a simple shell command around "git-bisect run",
> without any human interaction!"
>
> So it is reasonnable to wonder if some scripts might be parsing
> the output.

This reasoning sounds to me, that the lack of a plumbing counterpart to bisect(porcelain) made it a de facto plumbing command, which is unfortunate for discussing changes like these.

So how to proceed here?
* one way would be to ignore the scripts out there, "because it's
  porcelain, so nobody sane would have written a script using it anyway"
  but this attitude is not well perceived in the community I'd assume.
* declare the current bisect command a plumbing layer command and
  introduce a new porcelain command, how about "git find" which can address
  a variety of issues such as also having the capability to find a fix
instead of
  just regressions (make good/bad markers less confusing)
  Depending on the implementation this may be a lot of work
  -> copy/paste is fast and involves less work now, but more in the future
  -> or having a new plumbing-bisect header making calls from the porcelain
      to the plumbing bisect tool.