Merging changes from emacs-24 to master

Merging changes from emacs-24 to master

[Christoph]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

I just added rev b6cd03a to the emacs-24 branch (adding a file to
.gitignore). The same issue needs to be fixed in master. What is the
procedure to get the change from emacs-24 to master? Just cherry-pick the
change? What about the Changelog? Is it expected to be merged in also? Or
will there be a periodic bulk merge from emacs-24 to master?

Sorry, if this has been discussed before, but there are just too many
emails to keep up with. :)

Thanks,
Christoph

[-- Attachment #2: Type: text/html, Size: 541 bytes --]

Re: Merging changes from emacs-24 to master

[Eli Zaretskii]

> Date: Sat, 15 Nov 2014 14:18:34 -0700
> From: Christoph <cschol2112@gmail.com>
> 
> I just added rev b6cd03a to the emacs-24 branch (adding a file to .gitignore).
> The same issue needs to be fixed in master. What is the procedure to get the
> change from emacs-24 to master? Just cherry-pick the change? What about the
> Changelog? Is it expected to be merged in also? Or will there be a periodic
> bulk merge from emacs-24 to master?

There's no procedure yet.  When there will be, it will be based on
merges, like with bzr.

Re: Merging changes from emacs-24 to master

[Stefan Monnier]

> Just cherry-pick the change?

No: the emacs-24 gets *merged* to master.
Cherry-picking only happens when we go the other way (i.e. when we need
to port a patch from master to emacs-24).


        Stefan

Re: Merging changes from emacs-24 to master

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

>> Date: Sat, 15 Nov 2014 14:18:34 -0700
>> From: Christoph <cschol2112@gmail.com>
>> 
>> I just added rev b6cd03a to the emacs-24 branch (adding a file to .gitignore).
>> The same issue needs to be fixed in master. What is the procedure to get the
>> change from emacs-24 to master? Just cherry-pick the change? What about the
>> Changelog? Is it expected to be merged in also? Or will there be a periodic
>> bulk merge from emacs-24 to master?

> There's no procedure yet.  When there will be, it will be based on
> merges, like with bzr.

Here's how I would do it (assuming the standard layout of Lars's
document):
 cd ~/emacs/master/
 git merge --no-ff --no-commit emacs-24

After this, all successfully auto-merged files are staged and ready for
commit, and all files that got a conflict from the commit are waiting
for resolution.

I use magit http://magit.github.io/ to inspect the merge results. The
user interface is similar to svn-status and cvs-status:
 C-x d ~/emacs/master
 M-x magit-status RET

I've installed magit using ELPA (but not the official GNU ELPA)
 https://github.com/magit/magit#installation
(it's on both melpa and marmalade)

In magit I look at the diffs for all of the files that are staged for
commit and see if they are what I expected.

Files staged for commit that contain changes that should be in master
(e.g. files containing version numbers related to the emacs-24 branch),
are reverted (magit key 'k').  On the next merge git will remember this
resolution, and the change will not re-appear.

If some of the staged files with desired changes contain undesired
changes, such as e.g. version numbers, I manually edit the file to lose
those diffs, and save the file.  Then I re-stage the file in magit
(magit key 's'), and check the diff of the staged file again.

For conflicted files with a few lines of conflict, I try to resolve the
conflicts manually in emacs, until I get the desired diff, then I stage
the file from magit.

For conflicted files that really should come from one of the branches
(if merging to master, should come completely from master), I do this:
  git checkout origin/master example-file

If you refresh magit, the file will have disappeared from the staged
files for the commit.  Also this file will be excluded from the future
merges from emacs-24 to master.

After I'm satisfied that the diff looks sensible, I commit from magit
('c c') and edit the automatic merge commit message if necessary (most
of the time it isn't necessary, but sometimes it's useful to make a few
notes about conflict resolutions, in particular where a file was taken
completely from one of the branches).