| 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
| ||
|
Date: Fri, 3 Apr 2009 20:54:55 -0500 From: Felix Blyakher <felixb@....com> To: david@...g.hm 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 Apr 3, 2009, at 8:19 PM, david@...g.hm wrote: > 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. That was suggested among other things by Ingo Molnar as well. I'm planing to follow this approach. Thanks, Felix > > > 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/
Powered by blists - more mailing lists