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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Oct 2008 18:56:47 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [git pull] x86 updates for v2.6.28, phase #2 - PAT updates

* Ingo Molnar <mingo@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/