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

On 6/9/05, Linus Torvalds [off-list ref] 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.

quoted

quoted

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.

quoted

quoted

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