linux-kernel - Re: [GIT PULL] XFS update for 2.6.30

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.2.00.0904030954030.4130@localhost.localdomain>
Date:	Fri, 3 Apr 2009 10:02:15 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Felix Blyakher <felixb@....com>,
	Lachlan McIlroy <lachlan@...back.melbourne.sgi.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	xfs mailing list <xfs@....sgi.com>
Subject: Re: [GIT PULL] XFS update for 2.6.30

On Fri, 3 Apr 2009, Linus Torvalds wrote:

> 
> 
> On Thu, 2 Apr 2009, Felix Blyakher wrote:
> > 
> > Were there any problems pulling from the xfs repository?
> 
> Sorry, no - just too much email, too many trees to look at, too many 
> people to argue with.
> 
> Pulled.

Side note - I almost unpulled afterwards. 

You've done several apparently totally useless pulls from my tree at 
random points. 

Daily "keep up-to-date with Linus' tree" pulls are _strongly_ discouraged 
(read: if this continues, I'll just stop pulling from you), because it 
makes the history totally unreadable after-the-fact. It has some direct 
technical downsides (it makes it much harder to run "git bisect" and see 
what is going on), but apart from those direct downsides it just makes it 
much harder for me - or anybody else who wants to get an overview of what 
happened - to visualize things when history is messy.

Instead of having a clear nice line of development that says "this is what 
happened to XFS", those merges have basically mixed up all your changes 
with all the random _other_ changes in the tree. 

In other words, having those extra merges makes the graphical tools almost 
useless for getting some kind of "what happened" overview. 

I realize that an occasional back-merge may be required to resolve big 
conflicts early, but they really have to be pretty big and immediate for 
it to be a win. 

			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/