From: Paolo Bonzini <bonzini@gnu.org>
Date: Thu, 13 Nov 2008 16:41:07 GMT
Subject: Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
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.

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