Re: Upstream merging and conflicts (was Re: Using cvs2git to track an external CVS project)

[Martin Langhoff <martin.langhoff@gmail.com>]

On 6/9/05, Linus Torvalds <torvalds@osdl.org> wrote:
> Well, it's done, and it's now "much easier" in the sense that anything
> that doesn't have metadata changes should be picked up pretty trivially by
> the three-way merge thing.
> 
> But if you move things around, then you'd need to have a merge that is
> aware of movement, ie something much more sophisticated than just 3way
> merge.

I've followed the discussion and it's really good. I'll be playing
with the code on a cvs2git import I'm doing.

Two questions:
 - Is there a way to ask "what is the patchlog that you'll merge if I
ask you to merge from X"?
 - When an "automatic" merge happens, is there anything that
identifies commit with the commit that is being merged if the trees
are not identical? Is there a way to do that

What I am thinking of doing is having a perl (or bash?) script that
looks  at the changelog of two branches since they last converged,
looks at each commit and makes an educated guess of what patches are
in both and /facilitates/ extracting a patch the remote branch and
applying it locally with the same commit msg.

There are no promises on the guess -- it has to be reviewed & checked
-- but I find that is always true when trading patches across
branches. A lightweight, best-effort script to help someone who is
going to backport some patches from HEAD to the stable branch.

> > > It's true that you can't skip patches, since a merge is always
> > > all-or-nothing, and the global history really requires that (in a very
> > > fundamental way). However, you _can_ merge from the HEAD, and then say
> > > "that patch is no longer relevant in this tree", and remove it. Then
> > > you'll never need to worry about that patch any more, because you've
> > > merged it and in your merged result, it no longer exists).
> >
> > I had that strategy in my back-pocket already, but it doesn't sound right.
> 
> With global history, you really don't end up having much choice.
> 
> The alternative is to have per-file history, which sucks pretty bad

I don't quite follow you on why the per-file or per-tree worldview
affects this. Not very important though ;)

> My gut feel is that it should be possible to have a hybrid system that
> handles both the solid "crystalline" phase (aka git) and the "gas" phase
> (aka free-lowing patches) and have them integrate with each other well.
> That's kind of the way the kernel works, with people using quilt as a way
> to capture the patches in between.

Absolutement. For most projects I suspect that the gas (fluid?) phase
can be quite simple. In fact, simple is better.

> My read is that this analogy arch and darcs try to avoid the really solid
> crystalline phase entirely and end up being amorphous. You can probably
> have that too, but on the other hand it's fairly easy to merge between two
> "crystallized" repositories and be totally unambigious about what the
> result is, but if there's a lot of the amorpous stuff going on, it's not
> clear any more.

After a while, and a few thousand patches since you "branched",
patch-based SCMs don't help converge. At no point can they recognized
that 2 trees have converged and that the patch track becomes
irrelevant.

> > > Whether the kernel model is applicable to anything else, I dunno.
> >
> > I don't know either -- but I'm sure the toolset around git can support
> > a range of dev models. I don't think any other project has such a
> > large pool and strong convergence dynamics as the kernel. But git and
> > its tools and practices can be (I'm hoping) quite flexible to support
> > a range of dev models.
> 
> Hey, I obviously think you're right. Using git gives good ways of
> communicating the core infrastructure between two (or more) groups, while
> then internally within the group they may use loser patch-tracking systems
> that don't have the same kind of convergence requirements (but which you
> don't need for a "small" set of patches anyway, where "small" can
> obviously be hundreds of internal patches).

Interesting concept -- git as the head branch where everyone converges
while perhaps using other tools. Still... looser patch tracking
strategies can be based on git primitives, like some kind of commit
identity that travels with the merges, perhaps not to be used by git
but as a hooking point for naive patch tracking. But I suspect it may
be anathema to the git philosophy ;-)

cheers,


martin