Christian Couder [off-list ref] writes:
On Mon, May 11, 2015 at 6:54 PM, Junio C Hamano [off-list ref] wrote:
quoted
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.
...
quoted
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.
On Tue, May 12, 2015 at 7:11 PM, Junio C Hamano [off-list ref] wrote:
Christian Couder [off-list ref] writes:
quoted
On Mon, May 11, 2015 at 6:54 PM, Junio C Hamano [off-list ref] wrote:
quoted
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.
...
quoted
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.
On Tue, May 12, 2015 at 1:43 PM, Christian Couder
[off-list ref] wrote:
On Tue, May 12, 2015 at 7:11 PM, Junio C Hamano [off-list ref] wrote:
quoted
Christian Couder [off-list ref] writes:
quoted
On Mon, May 11, 2015 at 6:54 PM, Junio C Hamano [off-list ref] wrote:
quoted
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.
...
quoted
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.
On Tue, May 12, 2015 at 01:58:56PM -0700, Stefan Beller wrote:
On Tue, May 12, 2015 at 1:43 PM, Christian Couder
[off-list ref] wrote:
quoted
On Tue, May 12, 2015 at 7:11 PM, Junio C Hamano [off-list ref] wrote:
quoted
Christian Couder [off-list ref] writes:
quoted
On Mon, May 11, 2015 at 6:54 PM, Junio C Hamano [off-list ref] wrote:
quoted
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.
...
quoted
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.
honestly in this case I'd be inclined to go that route since the output
isn't really great for parsing so I do find it hard to believe there is
a reasonable number of scripts that use git bisect, and depend on its
output.
* 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)
Solving that issue would be nice, but I think git find is much less
intuitive to new people than bisect, but I'm not really a good judge of
that.
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.
my sense is that the division between git-bisect.sh and bisect--helper.c
isn't really great and could already use refactoring so I suspect it'd
be a fair amount of work.
Trev
On Wed, May 13, 2015 at 1:40 AM, Trevor Saunders [off-list ref] wrote:
my sense is that the division between git-bisect.sh and bisect--helper.c
isn't really great and could already use refactoring so I suspect it'd
be a fair amount of work.
About the division between git-bisect.sh and bisect--helper.c, yeah I
started converting git-bisect.sh into C code, but haven't finished
that.