On Tue, Oct 11, 2011 at 09:57:13PM -0700, Junio C Hamano wrote: > With an obvious addition of non-interactive short-cut subcommands "git > bisect yes" and "git bisect no", I think --removed= is a much better > wording than --used-to= I suggested in the discussion. Agreed. > I however am still worried about the flipping of the mapping between > <good,bad> and <yes,no> this design requires. What are we going to do to > the labels of low-level machinery (i.e $GIT_DIR/refs/bisect/bad and > $GIT/refs/bisect/good)? They appear in "bisect visualize" and I was hoping > that it would be simpler in the code if we do not have to change them in > such a way that depends on this introduced/removed switch, and that was > the reason why I was trying to see if we can solve this without the > switchable mapping between <good,bad> and <yes,no>. Hmm. I hadn't thought about the labels. In a yes/no situation, though, couldn't you use the labels as the user sees them? Then it is simply a matter of flipping yes/no inside the bisect script whenever we interact with the user (i.e., "git bisect yes") or when we interact with the on-disk labels. Certainly it's more complex than not allowing reversing, though. > More specifically, I was hoping that we can rename "good" to "old" and > "bad" to "new" unconditionally and be done with it. We would ask the user > "What did the code used to do in the olden days?" and "Does this version > behave the same as it used to?". The possible answers the user can give > are "git bisect old" (it behaves the same as the older versions) and "git > bisect new" (it behaves the same as the newer versions). Then we do not > have to worry about having to flip the meaning of <yes> and <no> at the UI > level. Hmm. I think this is not quite as nice, but it is way simpler. It may be worth trying for a bit to see how people like it. If they don't, the cost of failure is that we have to maintain "old/new" forever, even after we implement a yes/no reversible scheme. But maintaining the old/new mapping from yes/no would not be any harder than the good/bad mapping, which we would need to do anyway. So it sounds like a reasonable first step. -Peff -- 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