Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand

From: Paolo Bonzini <bonzini@gnu.org>
Date: Nov 13, 2008, 16:41 UTC
Message-ID: <491C58A3.2000609@gnu.org>
In-Reply-To: <200811121515.48277.chriscool@tuxfamily.org>

> 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.

Show 6 quoted lines

>> 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