Re: [git pull] x86 updates for v2.6.28, phase #2 - PAT updates

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 10 Oct 2008, Ingo Molnar wrote:
> 
> the time gap between v1 and v2 was rather large, 10 days:
> 
>  CommitDate: Sun Sep 14 17:50:41 2008 +0200
>  CommitDate: Wed Sep 24 10:07:52 2008 +0200
> 
> because it took time to find and track down the lockup, and it also took 
> time to come up with the fix. So i definitely wanted a delta fix (we 
> handle another 150 append-only commits in a 10 day timespan so a delta 
> fix is the right approach), but messed up its generation.

So because you wanted a delta fix, and if you want to keep the old series, 
then yes, creating a new (local-to-your-repository-only, throw-away) 
branch with the new "v2" series of patches, and then just applying them on 
top of the old broken series as incremental fixes would probably be the 
right thing to do.

With the reverts, there's not only all that useless noise in the logs, the 
problem is that all that extra crud is actually _hiding_ what the real fix 
was. So instead of seeing the fix, we just see a revert and a totally new 
version. That's pretty pessimal - the whole sequence isn't bisectable 
anyway.

So what I suggest are good alternatives would be:

 - Make things bisectable by just using a totally new branch (and dropping 
   the old branch). This just throws out the buggy version, since it never 
   gets merged upstream, and as such nobody will ever really care what the 
   bug was.

   This obviously depends on _others_ not having based their work on the 
   broken crud.

 - Make nice incremental fix patches, rather than "revert and redo". This 
   isn't bisectable, but on the other hand it can certainly be 
   educational, and "git blame" etc will give reasonable results, and 
   people seeing the history can at least see what the bug was.

I tried to outline a couple of ways to have git help you do the second 
version in the previous email. It's still going to be somewhat manual, but 
especially if the difference between patch-series wasn't _that_ big, a 
simple sequence of

	git checkout broken
	git diff broken..fixed | git apply
	.. see how you want to commit the fix - maybe as one thing, maybe 
	   as a series of independent fixes depending on the size of it ..

will get you there with fairly little pain.

Of course, if the branch had other commits to it than just the broken 
series, you will need to cherry-pick those other commits to the "fixed" 
branch too, so that the difference between broken and fixed is literally 
just the difference between the two patch-series.

Hmm?

		Linus