Re: Rewriting bzrmerge.el

[David Engster]

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.

-David