* 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
