[Top][All Lists]

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

Re: Rewriting bzrmerge.el

From: David Engster
Subject: Re: Rewriting bzrmerge.el
Date: Sat, 15 Nov 2014 17:26:41 +0100
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.91 (gnu/linux)

David Engster writes:
> Stefan Monnier writes:
>>> So, with bzr, we could pretty easily commit only the meta-data of
>>> skipped commits, so that they were regarded as merged.  But being the
>>> stupid content tracker that Git is, I think that ship has sailed.
>> AFAICT, there is no difference between Git and Bzr in this respect.
>>> We can of course cherry-pick a commit with the 'ours' merge strategy,
>>> but that will of course change the SHA1...
>> bzrmerge.el does not cherry-pick and neither should gitmerge.el.
> OK: It gradually builds up a merge from several small ones using
> different strategies.
>> It should identify those commits that are "backports" (or similar) and
>> merge them with the `ours' strategy (which will indeed leave the files
>> unchanged while affecting the metadata, AFAIK).
> But after a merge, 'git log emacs-24 ^master' should be empty, just like
> 'bzr missing ../emacs-24 --theirs-only' was empty, right?  You cannot
> achieve that with the 'ours' strategy, since it will not be the same
> commit anymore.

On second thought: Do you mean we should just merge them in a series of
merge commits (maybe in a temporary branch as to not pollute 'master'
too much)? That's easy, of course. I was hoping I could somehow
replicate the workflow we did with Bazaar, where we had one single merge
commit for each merge.


reply via email to

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