Jonathan Nieder wrote:
> - Importing <rev, path> pairs that have multiple parents. In the
> subversion model, path nodes have only one (copyfrom) parent,
> but repositories can use the svn:mergeinfo property to indicate
> that changes made in certain revs to another patch have been
The above should say "... changes made in certain revs to another
_path_ ...".
> incorporated. Under what circumstances is that enough
> justification to add a second parent on the git side?
One subtlety here is that sometimes people merge almost everything
from some branch but leave a few revisions out. Imagine the following
history:
o --- B1 --- B2 --- B3 ---- B4 -- F' ---- B6 --- B7 --- B8 [branch]
\ \ \
\ \ \
T1 --- F ------------------------ M1 ------------------ M2 [trunk]
The bugfix F was applied to the trunk first and then applied to the
branch as rev F'. Then the maintainer merged the remaining changes
B1, B2, B3, B4 from the branch to trunk. In git this operation would
be carried out by running "git merge branch". Finally some more
changes were made on the branch and the maintainer merged those to
trunk, too.
In subversion, this could be done like so:
1. Make commit T1 on trunk.
2. Make commit F on trunk.
3. Make commits B1, B2, B3, B4 on branch.
4. Make commit F' on branch, either using "svn merge" or by hand.
5. Merge changes B1, B2, B3, B4 from branch to trunk using
"svn merge -r o:B4 <url for branch>" and commit.
6. Make commits B6, B7, B8 on branch.
7. Merge changes B6, B7, B8 from branch to trunk using
"svn merge -r F':B8 <url for branch>" and commit.
The resulting svn:mergeinfo property on trunk in revision M1 would
look like this:
/branches/branch:B1-B4
To a naive importer, this looks like a merge of B4. The svn:mergeinfo
property on trunk in revision M2 would look like this:
/branches/branch:B1-B4,B6-B8
which looks like a bunch of cherry-picks rather than a merge, since
it looks like this almost-merge leaves out F'.
If the maintainer used "svn merge --reintegrate" instead, the
svn:mergeinfo properties are a little simpler, so maybe I am worrying
for no good reason. Anyway, hopefully that makes the setup a little
clearer.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html