Initial merge (was: Re: Merge or Cherry-Pick?)

[Johannes Sixt]

Am 2/3/2011 13:04, schrieb Johannes Sixt:
> Before anybody begins to work in this way, someone with sufficient
> knowlege must introduce the first real merge of the 4.6 branch into the
> master branch. The conflicts must be resolved; or it is possible to punt
> by using -s ours.
> 
> As long as this merge did not happen, anyone who wants to use the merge
> workflow is at a loss, unfortunately.

I tried to do the initial merges in kdelibs, kde-runtime, kde-baseapps,
and kde-workspace yesterday, and they turned out to be rather simple with
a surprisingly trivial result. Fast-forward to 5. below if you want to
know what it is.

The simplicity results from two assumptions:

(1) All back- and forward-porting was complete when SVN went
read-only.

(2) *.desktop and similar files are "generated" files, i.e., their content
is dictated from outside the repository.

Here is a recipe in case somebody wants to repeat the procedure on these
modules or apply it on other modules. IMVHO, this is the only right way to
do the initial merges:

1. I looked up the last SVN commits on branches KDE/4.3, KDE/4.4, KDE/4.5,
KDE/4.6, and master, and created local branches with these names. (I
included 4.3 as well because there was a recent commit on 4.3 in kdelibs.)
SVN commits contain "svn path" in the commit message. Watch out, one of
them was cherry-picked in kde-workspace; it does not count as the last SVN
commit.

2. I merged through with -s ours:

   git checkout KDE/4.4
   git merge -s ours KDE/4.3
   git checkout KDE/4.5
   git merge -s ours KDE/4.4
   git checkout KDE/4.6
   git merge -s ours KDE/4.5
   git checkout master
   git merge -s ours KDE/4.6

This is on the grounds that the SVN contents were "complete". Due to the
way how I set the branches, the -s ours hides only SVN commits, not any
new git commits.

3. Then in each branch, I merged the new git commit and the predecessor
branch:

   git checkout KDE/4.3
   git pull origin KDE/4.3

   git checkout KDE/4.4
   git pull origin KDE/4.4  # no conflicts possible!
   git merge KDE/4.3
   # resolve conflicts, see below
   git commit

   git checkout KDE/4.5
   git pull origin KDE/4.5  # no conflicts possible!
   git merge KDE/4.4
   # resolve conflicts, see below
   git commit

   git checkout KDE/4.6
   git pull origin KDE/4.6  # no conflicts possible!
   git merge KDE/4.5
   # resolve conflicts, see below
   git commit

   git checkout master
   git pull origin master  # no conflicts possible!
   git merge KDE/4.6
   # resolve conflicts, see below
   git commit

The pulls and merges involving KDE/4.[345] often do nothing ("Already
up-to-date") or do not conflict. Fine!

4. The interesting part is how to resolve the conflicts. Actually, notable
conflicts arose only when 4.6 was merged into master.

(a) Most conflicts arise from *.desktop and similar files. Here I assume,
that the files are machine generated (or copied from the i18n part of
SVN), and it would not matter how I resolved the conflicts because the
next Script Kiddy run would overwrite my efforts anyway. Therefore, I
resolved by taking the current version:

  git diff --name-only | grep '\.desktop$' | \
	xargs git checkout HEAD --

and similar for *.knotifyrc, *.directory, etc.

This command may fail if one of the *.desktop files was removed on one
branch. I used git-gui's "Use Local Version" command on them, and repeated
the command.

(b) This leaves a few conflicted files here and there. Investigate what
has happened with them:

   gitk --merge

and notice that most changes can be resolved to use the current version.
(Here, I usually use git-gui's "Use Local Version" command again or "Merge
Tool".)

(c) Not all *.desktop files conflicted. But with the same argument, that
any changes would be erased by Script Kiddy, any non-conflicting changes
need not be taken, either:

  git diff --cached --name-only | grep '\.desktop$' | \
	xargs git checkout HEAD --

and similar for *.knotifyrc, *.directory, etc.

(d) In git-gui, the list of staged changes is by now at most a hand-ful of
files. Notice that some resolutions introduce code twice - a classical
mis-merge. Undo that change, and notice that again the file contents boil
down to the current version.

(e) There is no (e).

5. Notice that due to the cherry-picking and "backporting" that was going
on even in the git time window since the weekend, in all 4 repositories,
only a single commit caused a code change in all the merges: Hugo's change
to kstyles/oxygen/oxygenstyle.cpp. All other merges turned out to be as if
made with git merge -s ours!!

I can offer a set of git bundles that contain the merge results. (I don't
have push access yet.) Anyone interested?

Hannes
-- 
"Atomic objects are neither active nor radioactive." --
Programming Languages -- C++, Final Committee Draft (Doc.N3092)