Michael Haggerty <mhagger@xxxxxxxxxxxx> 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. -- 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