Le vendredi 14 novembre 2008, Paolo Bonzini a écrit : > >> users could also set up a few > >> special bisect/set-debug-to-1, bisect/remove-cflags-o2 and so on > >> patches that you could use for purposes other than ensuring known bugs > >> are fixed. > > > > In this case it is similar to Junio's proposal. But I think that for > > changes like set-debug-to-1 and remove-cflags-o2, using the right make > > command should be enough. > > Yeah, I couldn't think of a better usecase, but you got the idea. > > >> Finally, you could have a [bisect] configuration section with entries > >> like "cherry-pick = BROKEN-SHA1 FIX-SHA1" and "git bisect" would apply > >> FIX-SHA1 automatically if the bisect tip were in > >> BROKEN-SHA1..FIX-SHA1. > > > > Yes, but how do you share this between members of a team? > > That's a common problem with stuff that goes in .gitconfig. It does not > belong in the repository, though... Why? Git encourages people to develop by creating many branches of commits, working on them and sharing them, and that seems to work very well. So I really don't understand why _the hell_ people using bisect could not also benefit of from creating patched up branches, sharing them, bisecting on them. Especially as, in my patch series, it does not in _any way_ change anything for people who just don't want to use patched up branches. They just need to not download any "bisect-replace-*" branch, or we can even implement a config option "bisect.useReplaceBranches" that default to "no" if that is such a big threat to them. I agree that the name of the branches "bisect-replace-*" may not be the best or that using special refs in "refs/replace/" might be better (except that these refs should have in my opinion a special namespace to be easily distinguished from others), but I don't think _at all_ that this should be enough to discard the whole idea (and implementation but that's another story). Or is there a god command I don't know about that says: Thou shall not use patched up branches to bisect! Thou shall bisect painfully! Regards, Christian. -- 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
