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

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

(reposted with appropriate subject)

On 6/2/05, Anton Altaparmakov <aia21@cam.ac.uk> wrote:
> Disregarding anything about cvs2git there is one point you may not be
> thinking about but you may want to care about:  when you send something
> upstream to the cvs repository and then get it back via cvs2git you will
> get a completely different commit to the one your local git repository
> has.

If upstream hasn't touched the files I'm patching, and cvs2gig/cvs2ps
use -kk there is some hope that the objects should be the same...
right?

>  So while the file changes inside those two commits are the same
> the actual commits are not and you will end up with all those commits in
> duplicate because of it as well as an automatic merge commit to merge
> the two commits.

So, this is the scenario for a situation where the files I'm patching
have changed upstream, so upstream merges my patch on top of previous
patches, and I get commit objects echoed back that logically contain
my patch but git sees as different.

Is it any better if upstream is using git as well? Is there any chance
for a private branch or tree to survive anything but a "perfect match"
merge where upstream and the branch are in perfect sync before and
after?

I understand this is architected to _not_ support cherry picking in
the darcs/arch sense and I think it's a good idea. But it seems than
any non-trivial merge ends up being a completely manual process.
Anyone having to work on a series of patches for Linux that get
accepted in stages is going to find himself forced to a potentially
time-consuming remerge every time Linus does a partial merge. Argh.

So it seems to me that git is well suited for a set of closely related
HEADs that are very aggressive in synching with each other. Synching
work is pushed out to the peripheral branches -- a design decision I
agree with -- but there's very little support to help me keep a
peripheral branch in sync.

The assumption that those peripheral branches must be short-lived and
discardable is valid for a limited set of cases -- very circumscribed
to short-term dev work. As soon as a dev branch has to run a little
longer, it cannot afford to not sync with the HEAD. Particularly, it
cannot skip a _single_ patch coming from HEAD.

And if I'm doing development from my branch and pushing to HEAD, and
the guy doing the merge in HEAD merges my patches in a different order
I'll have a spurious conflict.

I use peripheral branches to track versions of code in production,
that may have different sets of patches applied. For that purpose,
patch-based SCMs are quite helpful (you can ask what patch is applied
where), but as Linus pointed out, they don't actually help convergence
at all. Git pulls towards convergence like a demon AFAICS -- yet some
primitive patch trading smarts would save a lot of effort at the
borders of the dev network.

cheers,


martin