On Apr 22, 2014, at 11:54 AM, Eric Wong <normalper...@yhbt.net> wrote:
> Jakob Stoklund Olesen <stokl...@2pi.dk> wrote:
>> Subversion can put mergeinfo on any sub-directory to track cherry-picks.
>> Since cherry-picks are not represented explicitly in git, git-svn should
>> just ignore it.
> Hi, was git-svn trying to track cherry-picks as merge before?
It would try and fail. I didn't explain that properly in the commit message.
Suppose I have a standard svn layout with $url/trunk and $url/branches/topic1.
My topic1 branch has a change in subdir1 that I want to cherry-pick into trunk:
% svn switch $url/trunk
% cd subdir1
% svn merge $url/branches/topic1/subdir1
% cd ..
% svn commit
This operation will set svn:mergeinfo on $url/trunk/subdir1 where a normal full
merge would set it on $url/trunk:
% svn pg svn:mergeinfo subdir1
When git-svn fetches these changes, it currently does examine the svn:mergeinfo
change on the subdirectory as if it were a full merge. It then fails to find a
revmap for /branches/topic1/subdir1:
Couldn't find revmap for file:///tmp/sdb/branches/topic1/subdir1
r5 = 5ce1f687c30495deca40730fb7be3baa0e145479 (refs/remotes/trunk)
It is looking for refs/remotes/topic1/subdir1, but we only have the
refs/remotes/topic1 branch in git.
This patch makes git-svn stop trying to reconstruct those subdirectory merges
that we know will fail anyway.
> This changes behavior a bit, so two independent users of git-svn
> may not have identical histories as a result, correct?
For normal subdirectory cherry-picks as described above, the behavior doesn't
change. This is just a performance optimization.
For weirder cases where a whole branch has been merged onto a subdirectory of
trunk, behavior does change. Currently, git-svn will mark that as a full merge
in git. With this change it won't.
> Can you add a test to ensure this behavior is preserved?
I'll add a test for the subdirectory merge described above.
> Sorry, I've never looked at mergeinfo myself, mainly relying on
> Sam + tests for this.
>  - Historically, git-svn (using defaults) has always tried to
> preserve identical histories for independent users across
> different git-svn versions. However, mergeinfo may be
> enough of a corner-case where we can make an exception.
I agree. It doesn't seem worthwhile to try to preserve git-svn's historical
behavior in weird corner cases.
BTW, this performance optimization matters not because of sporadic manual
cherry-picks, but because certain older svn releases would replicate
svn:mergeinfo on every subdirectory in a standard merge. With hundreds of
subdirectories and thousands of merged branches, git-svn gets completely stuck
processing all those mergeinfo lines.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html