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)