On Wed, 14 May 2014 01:29:29 +0200 (CEST) Jiri Kosina <jkosina@suse.cz> wrote:

> On Wed, 14 May 2014, NeilBrown wrote:
> 
> > A particular practical issue is that when doing a git-bisect there might 
> > be a range of commits that only compile/run if some later commit is 
> > applied. If I'm bisecting in that range, I have to repeatedly apply that 
> > commit by hand.
> 
> You can just have it stored in a separate branch and perform the bisection 
> using a script that will always first merge the branch, and reset after 
> good/bad verification is done.
> 
> If the fix is already applied (because you are testing a state of the tree 
> which has the commit already), git handles the merge of the 
> already-applied patch with grace even if they don't have the same SHA-1.
> 

True.  But every extra step I have to add to a script is an extra barrier to
performing what is already a somewhat tedious task.

If fixes were always Strongly-Attached to the commit they fix, then I
wouldn't even need to find these "fix-up" patches.  One person commits the
fix in the "right" way, and everyone benefits.

Thanks,
NeilBrown