On Apr 22, 2014, at 11:54 AM, Eric Wong <normalperson@xxxxxxxx> wrote: > Jakob Stoklund Olesen <stoklund@xxxxxx> 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 /branches/topic1/subdir1:3-4 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. Thanks, /jakob -- 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