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?
> Thanks.

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.
> [1] - 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

Reply via email to