GeezerVison

This is a huge commit. Is it possible to merge the maintenance branches one at a time, or is there benefit to merging them all at once?

I'm just trying to understand exactly what this is, since I am just learning about strategy=ours. Did you run this command on the master to merge from the branch, eg

git checkout master
git merge maint_branch --strategy=ours

with the strategy=ours saying keep all the master files as is. I see the diff is empty in your pull request, which is what we would want since the changes have already been merged. What then gets updated in master exactly, the commit DAG?

Darren: it's possible to merge one at a time, or to merge only the active maintenance branch (which means that if we ever need to update one of the older branches, we can't merge it into master, or we'll get a huge merge at that time).

John: what I did was

git checkout -b merge-maint-branches master
git merge --strategy=ours origin/v1.0.x origin/v0.99.x origin/v0.98.x origin/v0.91.x
git commit --amend # to edit the commit message

Yes, the diff against master should be empty, and what gets updated is the commit DAG. The merge operation makes all the commits in the various branches ancestors of this commit, so after this commit is merged into master, merging any of the maintenance branches into master will not try to apply any of those ancestral commits. If it's unclear, try viewing this in gitk (or gitx or the various other GUIs) or adding practice commits into a local copy of a maintenance branch and merging them into master before and after this change.

In principle git2svn could have done this based on our svnmerge.py information, and it seems that it has worked partially. The git branch model is a DAG where any merge has both (or all) merged branches as ancestors, whereas the svnmerge model is that each commit either has or has not been applied to a given branch, and you can pick and choose which ones to merge in at a time. The svnmerge "merges" correspond more the git's "cherry-pick" functionality, except that svnmerge attempts to keep track which diffs have been included and git cherry-pick does not.

Thanks for the clarification. I misunderstood what this pull request was doing. I thought it was actually pulling all non-conflicting commits from the various maintenance branches into master. I withdraw my comment about applying it one branch at a time.

I wonder if this has anything to do with the minor annoyance we always had with svnmerge.py where various files not modified by the commit were still having their properties changed? I looked into it once, and I found that the property being changed had something to do with changing which revision number a file was being merged from (or something like that).

I wonder if this should be done iteratively, meaning:

git checkout v0.98.x
git merge --strategy=ours v0.91.x
git commit --amend
git checkout v0.99.x
git merge --strategy=ours v0.98.x
git commit --amend
git checkout v1.0.x
git merge --strategy=ours v0.99.x
git commit --amend
git checkout master
git merge --strategy=ours v1.0.x
git commit --amend

That way, just in case anyone submits a patch against an older version than 1.0.x, we can always apply it and propagate it up the chain.

Darren: you're right, that's a better way to do this. I think it will involve several pull requests, since we have to merge into each branch separately.

Ok, I'm closing this pull request so we can handle it that way.