Re: patch vs. overwrite in bzr

[David Engster <deng@randomsample.de>]

Bastien writes:
> Óscar Fuentes <ofv@wanadoo.es> writes:
>> Stefan's advice has nothing to do with bzr. It is about not blindly
>> overwriting changes made on the emacs repo with the new version of the
>> externally-maintained package (`Org' is in this case.) Applying a patch
>> gives a lot more opportunities for noticing conflicts (suppossing that
>> the hacker cares to examine the output of the patch command, that is.)
>
> The problem is: how to create a patch from Org git repo that can be
> easily applied to Emacs bzr repo.
>
> If someone can come up with a workable solution, that'd help me a lot.
>
> Oscar, you said:
>
>> I suggest that, before syncing, you obtain a diff from the bzr (or git)
>> emacs repo that contains all changes to org since your last sync, commit
>> the diff onto your org sources and then proceed with the new sync.
>
> Which is theoretically fine... but if someone can actually *test* the
> suggested workflow, I'm all ears.

I'm in the process of writing a merge tool cedet-emacs-merge.el
('ceemme') for the upcoming CEDET/Emacs merges. You can find a very
rough first revision in our 'newtrunk':

http://cedet.bzr.sourceforge.net/bzr/cedet/code/newtrunk/files

Now, it clearly cannot be used straight away for org, since we're using
bzr and there are some very CEDET specific things in the code when
adapting paths and stuff like that, but it might give you an idea how
I'm planning to do things. Again: it's very early and I'm not using it
in production yet (will happen when Eric has released the current trunk
as 1.1).

In a nutshell: It's more or less a GUI to do cherry picking with bzr and
marking commits as 'applied', 'ignored' etc. and saving that state in
the repository between sessions. In the end it will work in both
directions, but currently I'm concentrating on the Emacs -> CEDET, since
this will be the first thing to do next. Also, for the other direction
we will probably use a dedicated branch like 'for-emacs' or something
like that and not directly push into Emacs.

If you or someone else would be interested into making this into a more
generic cross-project merge tool - I am all ears. However, I could also
imagine that there might be some git-trickery using submodules or
whatever which allows a more elegant workflow.

-David