Junio C Hamano <gitster@xxxxxxxxx> writes: > Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > >> And indeed "git bisect terms foo bar" errors out. I think the reason it >> is this way is to allow >> >> $ git bisect terms foo bar >> $ git bisect start <sha1> <sha1> >> >> But actually, we can allow "git bisect terms" until BISECT_TERMS is >> created, which is your intuition and makes more sense IMHO. I'll try to >> do that. > > I am not sure if it is a good idea, though. Matching the intuition > of those who (think they) know how it is implemented is much less > important than providing a behaviour that is simple to explain to > casual users. I thought about it a bit more. Essentially, we have two options simple to implement: 1) Allow `git bisect terms` when BISECT_TERMS does not exists. This prevents running `git bisect terms` twice in a row, but would match your first guess: we could still run it until the terms are commited. Pro: it feels more natural to me to write git bisect start git bisect terms foo bar ... git bisect reset => everything happens between start and reset. 2) Allow `git bisect terms` when BISECT_START does not exist (the current implementation). I'm keeping option 2) for now, but if anyone think option 1) is better, it shouldn't be hard to change. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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