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

[Ingo Molnar <mingo@elte.hu>]

* Ingo Molnar <mingo@elte.hu> wrote:

> > which makes both the original commit _and_ the revert just totally 
> > pointless, because we didn't learn anything.
> 
> hm, those reverts werent supposed to survive. Again, my bad. I'll 
> clean it out.
> 
> Here is how the screwup happened: a series was sent, i applied it, 
> found a test failure with it and reported it:
> 
>   http://www.uwsg.iu.edu/hypermail/linux/kernel/0809.1/2388.html
> 
> but to be able to continue testing i temporarily reverted those bits 
> manually in reverse order, because it took some down to pin down the 
> breakage and these bits got intermixed with other commits - and i did 
> not want to rebase commits that came after the broken series.

Correction: i did the reverts shortly before applying the v2 series - so 
it was fully technical. I wanted to do a line by line review of the fix 
(and did it), because the lockup took quite some time to pin down. To 
avoid this mistake i could also have hard-reset the full v1 series and 
could have redone the whole topic.

What's the best Git way to avoid such mishaps? I try to avoid resets and 
rebases of already pushed out bits as much as possible, because that is 
both risky because information can be lost and asocial because ongoing 
work of contributors can be disturbed.

	Ingo