From: Junio C Hamano <hidden> Date: 2016-06-15 23:05:33
Matthieu Moy [off-list ref] writes:
quoted
Matthieu Moy [off-list ref] writes:
quoted
+ git bisect terms <term-old> <term-new>
I think this is the other way around.
Indeed.
I hate to be saying this, but this is a strong indication that
consistency with "start $bad $good..." must be broken. If the
person who has been working on this topic for a few iterations in
the past few days cannot get it right, no ordinary user can. With
or without a mnemonic hint "N comes before O, so does B before G".
Of course we cannot just say "git bisect terms old new". That would
only invite "eh, I do not remember, which between terms and start
take the old one first?" without helping people.
The best I can come up with is to forbid positional arguments to
this subcommand and always require them to be given like so:
git bisect terms --old=fast --new=slow
git bisect terms --new=slow --old=fast
We may want to start supporting
git bisect start --new=master --old=maint
while at it and then gently nudging people to stop using
git bisect start master maint
by showing depreation notice.
From: Christian Couder <hidden> Date: 2016-06-15 23:05:33
On Sat, Jun 27, 2015 at 12:25 AM, Junio C Hamano [off-list ref] wrote:
Matthieu Moy [off-list ref] writes:
quoted
quoted
Matthieu Moy [off-list ref] writes:
quoted
+ git bisect terms <term-old> <term-new>
I think this is the other way around.
Indeed.
I hate to be saying this, but this is a strong indication that
consistency with "start $bad $good..." must be broken. If the
person who has been working on this topic for a few iterations in
the past few days cannot get it right, no ordinary user can. With
or without a mnemonic hint "N comes before O, so does B before G".
Of course we cannot just say "git bisect terms old new". That would
only invite "eh, I do not remember, which between terms and start
take the old one first?" without helping people.
The best I can come up with is to forbid positional arguments to
this subcommand and always require them to be given like so:
git bisect terms --old=fast --new=slow
git bisect terms --new=slow --old=fast
If we don't want to support positional arguments, then I would suggest
supporting first the following instead:
git bisect terms --name-good=fast --name-bad=slow
git bisect terms --name-bad=slow --name-good=fast
This would make the interface consistent with the code.
Of course we could also accept --name-old and --name-new as synonyms
for --name-good and --name-bad.
We may want to start supporting
git bisect start --new=master --old=maint
Maybe we could also support:
git bisect start --name-good=fast --name-bad=slow --fast=maint --slow=master
From: Junio C Hamano <hidden> Date: 2016-06-15 23:05:33
On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
[off-list ref] wrote:
If we don't want to support positional arguments, then I would suggest
supporting first the following instead:
git bisect terms --name-good=fast --name-bad=slow
git bisect terms --name-bad=slow --name-good=fast
This would make the interface consistent with the code.
Which somewhat defeats the point of introducing "old" and "new", though.
The "terms" support is for people who feel that good/bad would be too confusing
for the particular bisect session (e.g. because they are hunting for a fix).
quoted
We may want to start supporting
git bisect start --new=master --old=maint
Maybe we could also support:
git bisect start --name-good=fast --name-bad=slow --fast=maint --slow=master
The same comment for the token after --name-, but allowing the terms to be set
at "start" could be a type-saver. With need for added "--name-"
prefix (worse, twice),
I am not sure if it would be seen as a useful type-saver, though.
Thanks.
From: Christian Couder <hidden> Date: 2016-06-15 23:05:33
On Sat, Jun 27, 2015 at 6:25 AM, Junio C Hamano [off-list ref] wrote:
On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
[off-list ref] wrote:
quoted
If we don't want to support positional arguments, then I would suggest
supporting first the following instead:
git bisect terms --name-good=fast --name-bad=slow
git bisect terms --name-bad=slow --name-good=fast
This would make the interface consistent with the code.
Which somewhat defeats the point of introducing "old" and "new", though.
The "terms" support is for people who feel that good/bad would be too confusing
for the particular bisect session (e.g. because they are hunting for a fix).
Well if --name-old and --name-new are also available as synonyms, it
would not be too bad I think.
People could use the option names that fit their mental model or their
use case better.
quoted
quoted
We may want to start supporting
git bisect start --new=master --old=maint
Maybe we could also support:
git bisect start --name-good=fast --name-bad=slow --fast=maint --slow=master
The same comment for the token after --name-, but allowing the terms to be set
at "start" could be a type-saver. With need for added "--name-"
prefix (worse, twice),
I am not sure if it would be seen as a useful type-saver, though.
At least people don't need to remember if they have to use "git bisect
term" before or after starting :-)
From: Michael Haggerty <hidden> Date: 2016-06-15 23:05:33
On 06/27/2015 06:25 AM, Junio C Hamano wrote:
On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
[off-list ref] wrote:
quoted
If we don't want to support positional arguments, then I would suggest
supporting first the following instead:
git bisect terms --name-good=fast --name-bad=slow
git bisect terms --name-bad=slow --name-good=fast
This would make the interface consistent with the code.
Which somewhat defeats the point of introducing "old" and "new", though.
The "terms" support is for people who feel that good/bad would be too confusing
for the particular bisect session (e.g. because they are hunting for a fix).
quoted
quoted
We may want to start supporting
git bisect start --new=master --old=maint
Maybe we could also support:
git bisect start --name-good=fast --name-bad=slow --fast=maint --slow=master
The same comment for the token after --name-, but allowing the terms to be set
at "start" could be a type-saver. With need for added "--name-"
prefix (worse, twice),
I am not sure if it would be seen as a useful type-saver, though.
I would like to remind everybody of my old claim that it would be
possible to teach `git bisect` to infer by itself which term means
"older" and which term means "newer":
http://article.gmane.org/gmane.comp.version-control.git/244036
I think that making `bisect` smarter could make the UI simpler, though
admittedly it would be more work than the current proposal.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
But then one mistake at the beginning and the user will be on a wrong
track during the whole bisect session, no? Unless you make absolutely
clear when making the "intelligent" decision what Git inferred, that is.
For something complex like bisect, I highly suspect that a tool that is
more intelligent than the end users (more precisely, a tool that it thinks
it is more intelligent) would hurt them more than it helps them.
Of course, that is only my claim ;-)
But then one mistake at the beginning and the user will be on a wrong
track during the whole bisect session, no? Unless you make absolutely
clear when making the "intelligent" decision what Git inferred, that is.
Definitely, `git bisect` should tell the user what it inferred.
For something complex like bisect, I highly suspect that a tool that is
more intelligent than the end users (more precisely, a tool that it thinks
it is more intelligent) would hurt them more than it helps them.
This isn't about making bisect "more intelligent than the end users". It
is about not forcing the user cumbersomely to spell out redundant
information because the tool is too stupid.
If I mark one commit "broken" and another commit "fixed", and the
"broken" commit is an ancestor of the "fixed" commit, then it is pretty
obvious that I am looking for the commit that caused the transition
"broken" -> "fixed". The same if I mark one commit "xyzzy" and the other
one "plugh".
I understand that the user might make a mistake when marking the initial
commits, but as soon as bisect says
Commit <sha1-abbrev> is an ancestor of <sha1-abbrev>, so I
will look for the commit that caused the transition from
"xyzzy" to "plugh".
then I hope the user will notice and correct her/his mistake.
For example, a session could be started with
git bisect start --mark=broken <committish> --mark=fixed <committish>
and from then on
git bisect broken
git bisect fixed
Or, if the user doesn't want to specify both endpoints on the `start` line,
git bisect start
git bisect --mark=broken [<committish>]
git bisect --mark=fixed [<committish>]
Essentially, specifying `--mark=<name>` once would make `<name>` a
shorthand for `--mark=<name>`.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
But then one mistake at the beginning and the user will be on a wrong
track during the whole bisect session, no? Unless you make absolutely
clear when making the "intelligent" decision what Git inferred, that is.
Definitely, `git bisect` should tell the user what it inferred.
quoted
For something complex like bisect, I highly suspect that a tool that is
more intelligent than the end users (more precisely, a tool that it thinks
it is more intelligent) would hurt them more than it helps them.
This isn't about making bisect "more intelligent than the end users". It
is about not forcing the user cumbersomely to spell out redundant
information because the tool is too stupid.
If I mark one commit "broken" and another commit "fixed", and the
"broken" commit is an ancestor of the "fixed" commit, then it is pretty
obvious that I am looking for the commit that caused the transition
"broken" -> "fixed". The same if I mark one commit "xyzzy" and the other
one "plugh".
I understand that the user might make a mistake when marking the initial
commits, but as soon as bisect says
Commit <sha1-abbrev> is an ancestor of <sha1-abbrev>, so I
will look for the commit that caused the transition from
"xyzzy" to "plugh".
then I hope the user will notice and correct her/his mistake.
This looks fragile to me. Unfortunately many users will probably not
read it and continue, and then spend a lot of time later trying to
understand what went wrong, not remembering about the message at all.
The message looks like an informative message. At least we should add
something like "Please check that it is what you want to do and abort
with 'git bisect reset' if it is not."
For example, a session could be started with
git bisect start --mark=broken <committish> --mark=fixed <committish>
This look nearly the same as:
git bisect start --name-old=broken --broken=<committish>
--name-new=fixed --fixed=<committish>
except that it looks safer and more backward compatible to me with
--name-old and --name-new.
By the way we could use "mark" or "term" instead of "name" in the
option name (like --mark-old or --term-old) and in the code too if it
looks clearer.
and from then on
git bisect broken
git bisect fixed
Or, if the user doesn't want to specify both endpoints on the `start` line,
git bisect start
git bisect --mark=broken [<committish>]
git bisect --mark=fixed [<committish>]
We could do that too with:
git bisect start
git bisect --name-old=broken broken [<committish>]
git bisect --name-new=fixed fixed [<committish>]
and/or:
git bisect start
git bisect --name-old=broken --broken=[<committish>]
git bisect --name-new=fixed --fixed=[<committish>]