linux-kernel - Re: [GIT pull] x86 fixes for 2.6.26

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.LFD.1.10.0805161831380.3020@woody.linux-foundation.org>
Date:	Fri, 16 May 2008 18:38:26 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
cc:	tglx@...utronix.de, linux-kernel@...r.kernel.org, mingo@...e.hu,
	hpa@...or.com
Subject: Re: [GIT pull] x86 fixes for 2.6.26

On Fri, 16 May 2008, David Miller wrote:
> 
> I think I merged from Linus's tree only 3 or 4 times maximum since I
> created that tree way back when the 2.6.26 merge window opened up.

Basically, a rule-of-thumb would be "once a week is reasonable", but on 
the other hand, if you have actual conflicts, more often is fine, and if 
you know your area isn't impacted (eg most filesystems), you'd probably 
only try to synchronize at release points or something like that.

The reason to avoid doing overly many merges is

 - merging with me at random points is usually not a good idea anyway, 
   unless you have a really strong reason for it. Yes, my tree is fairly 
   stable, but still..

   (This also implies that merging with my *tags* is usually a better idea 
   than merging with some random point in time, and is one reason it makes 
   sense to try to merge with major releases rather than anything else)

 - the history just looks cleaner and is easier to follow when there 
   aren't criss-crossing merges.

   This may not matter most of the time, but it *does* make a difference 
   when doing "git bisect". I don't know about others, but I often do "git 
   bisect visualize" then I have some totally unknown bug and I'm trying 
   to guess what's going on - it's a great way to give people a heads up 
   saying "ok, I'm in the middle of a bisection run, and it _looks_ like 
   it may be due to you".

So trying to have fairly clean history is worth it (it also makes it 
slightly faster to bisect when you don't have lots of criss-cross merges, 
but that's a fairly small factor).

> If users, or even you, want to get a bug fix from Linus's tree or check
> if there will be merge conflicts, just create a test branch and play
> with such things there.

Yes. I think you guys already have a test branch for the "join it all 
together" case, don't you?

		Linus
--
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/