Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH] bisect: revise manpage

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:05:33

Michael Haggerty [off-list ref] writes:
By the way, when I was revising the text two things occurred to me that
have probably been discussed to death elsewhere but let me mention them
anyway:

1. I found it confusing that `git bisect terms` lists its arguments in
the order `<term-new> <term-old>`. I think that listing them in
"chronological" order would have been a lot more intuitive. But I expect
this choice was made because `git bisect start` takes optional arguments
in that order, so the inconsistency might be worse than the backwardness
of this single command's arguments.
Consistency with 'start' is truly a good motivaition.  And 'start'
asking for 'bad' first is not backwardness but comes primarily from
syntactic need.  You need one and only one 'bad' and can give zero
or more 'good' to the command, so "start bad [good...]" becomes a
more natural way than "start [good...] bad" to form a command line.
2. When I was describing "old/new", I kept wishing that I could type
"before/after" instead, because those terms seemed to agree better with
the prose description of what "old/new" mean. I wonder if "before/after"
might be better names for commits determined to be before/after the
change being sought?
Yeah, I like that, but I do not think replacing 'old/new' with
'before/after' is worth the trouble.  Both would work equally well
at least for me.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help