> Of course it also depends on how often people use "git bisect", but it seems > that there are people out there bisecting very frequently and that these > people care very much about bisectability of the tree. What about "git bisect cherry-pick COMMIT" which would do a "cherry-pick -n" of COMMIT after every bisection unless COMMIT is in the ancestry of the current revision? So if you have to bisect between A and B, and you know that a bug present between A and B was fixed by C, you could do git bisect good A git bisect bad B git bisect cherry-pick C This would subsume Junio's proposal: 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. 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. >> Things like paranoid update hook >> needs to become very careful about refs/replace/ for security reasons, >> but I think this would make the grafts much easier to use. > > I agree that it would make grafts much easier to use (and would be very > security sensitive). Not so much. People with public servers could create refs/replace in the server and give it 400 permissions, and/or git would refuse to create the refs/replace directory, forcing users to create it manually unless it is already in the server. Paolo -- 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
