* David Woodhouse <[EMAIL PROTECTED]> wrote: > On Fri, 2005-04-15 at 11:36 +0200, Ingo Molnar wrote: > > do such cases occur frequently? In the kernel at least it's not too > > typical. > > Isn't it? I thought it was a fairly accurate representation of the > process "I make a whole bunch of changes to files I maintain, pulling > from Linus while occasionally asking him to pull from my tree. > Sometimes my files are changed by someone else in Linus' tree, and > sometimes I change files that I don't actually own.".
but the specific scenario you described would require _Linus'_ tree to be in limbo for a long time, and have uncommitted half-done edits. I.e.: (A1B2)--(A2B2)--(A2'B3) / \ / \ / \ / \ (A1B1) X (...) \ / \ / \ / \ / (A2B1)--(A2B2)--(A3B2') in the above scenario Linus' tree needs to 'cross' with a maintainer's tree. (maintainer's tree wont cross with another maintainer's tree, as maintainer-to-maintainer merges rare.) but for the scenario to occur, i think there needs to be a prolongued "limbo" period in Linus' tree for a 'crossing' to happen. But Linus' merges are typically almost atomic: they are done then they are pushed out. It's definitely not in the 'days, sometimes weeks' timescale as maintainer trees are. so for the scenario to occur, a maintainer, from whom Linus has just pulled an update and Linus is merging the tree manually without comitting, has to pull a file from the earlier Linus tree, and then Linus has to modify that same file again. This does not seem to be a common scenario. so i think to avoid the scenario, maintainers should not pull from each other - they should only pull/push to/from Linus' tree. Maybe this is an unacceptable limitation? Ingo - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html