[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Having a custom merge process

From: David Engster
Subject: Re: Having a custom merge process
Date: Sat, 26 Dec 2015 00:59:40 +0100
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.5 (gnu/linux)

Lars Ingebrigtsen writes:
> John Wiegley <address@hidden> writes:
>> I've used Git in many scenarios, on many projects, but some of the practices
>> we're using here for Emacs development I've never seen before. This simply
>> makes me wonder how much of that difference is truly necessary, or is a 
>> result
>> of having evolved to this point from CVS and then Bazaar.
> I think the latter is probably true.  There are many people here who
> aren't that fond of git.  (I'm one of them.  :-))  And that's probably
> somewhat unusual, these days.
> But as I see it, other projects just accept gits many, many
> peculiarities and live with them, but in the Emacs toolchain we've (I
> mean, not me; I had nothing to do with it) tried to create a layer of
> sanity and reliability over the gittishness...
> Hey!  It's time for a new 500+ article VC thread!

Nah, this script does not really have much to do with Git. We had pretty
much the same script for Bazaar, I just rewrote it. The main point is
still that you want to do a full merge of 'emacs-25', but you want to
skip the content of certain commits along the way (in other words: you
want to use the merge strategy 'ours' for those commits). Git does not
directly support this, and neither did Bazaar. At least Git can often
detect cherry-picks, but as I've written, it sometimes fails, and not
every commit we want to skip is a backport.

The usual way to deal with this is to have one person who does the
merges ("the Merge Master"), who needs to have a good overview of
development and the used VCS and hence simply knows what to do. The
point of gitmerge.el is that pretty much anyone should be able to do the


reply via email to

[Prev in Thread] Current Thread [Next in Thread]