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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 3 Apr 2009 18:19:08 -0700 (PDT)
From:	david@...g.hm
To:	Felix Blyakher <felixb@....com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Lachlan McIlroy <lachlan@....com>,
	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, Felix Blyakher wrote:

> On Apr 3, 2009, at 12:02 PM, Linus Torvalds wrote:
>
>> 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.
>
> That was my concern, i.e. it's not pulled without explicit
> NAK. I knew about your possible concerns.
>
>> You've done several apparently totally useless pulls from my tree at
>> random points.
>
> Yes, I noticed that, and agree with all your points even
> before you brought them up.
> I already started talking to people to improve my process.
> The reason the intermediate pulls from your tree were done
> is to make sure that new xfs patches would not conflict
> with some other changes already in the mainline. That was
> part of the maintainer cheat sheet given to me, and I
> didn't realize the side effects of it.
> I probably can verify the possible conflicts without pushing
> the merges into the repository and reset the working tree to
> pre pull state.

create a temporary branch and do the merge in that. then throw away the 
test branch and there is no harm to the main tree.

David Lang

> At any rate, I'll find some way to manage that without
> cluttering the history with the merges.
> Any suggestions are welcome.
>
> Thanks,
> Felix
>
>> 
>> 
>> 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/
--
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/