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

Linus Torvalds
2008-10-10T17:35:25Z

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