Steven Grimm wrote: > I will say, though, that the upcoming addition to git-svn to allow > merges to be directly committed to the svn repository will make some of > those kinds of scenarios a lot less brittle than they are now. It's > still a work in progress but it looks very promising so far. (Search the > list for "[PATCH] git-svn: allow dcommit to retain local merge > information" if you want to see what I'm talking about.) Yes. On that. It would be nice if git-svn could also fake setting remote merge properties, too. Some beginnings at: http://git.catalyst.net.nz/gw?p=git.git;a=shortlog;h=svk-merge (pull from git://git.catalyst.net.nz/git.git#svk-merge) What it needs to do; 0. preserve the notion that commits tagged with "git-svn-id:" should not vary depending on who synced them. 1. on commit, if we're committing a merge, make sure that the other parent has the same revision somewhere in the repo, and then set the "svk:merge" and "svnmerge-integrated" tags to accurately record which parent SVN revisions are used 2. when fetching revisions, spot these tickets and set parents appropriately. In the case of SVK, the merge tickets may correspond to revisions in (inaccessible) svk local depots. It may be possible to infer these extra parents in some limited situations using the extra information svk puts in commit messages by default, but I doubt that is a useful endeavour! I'll take a look at what you've been working on and see if that's not what you're already trying... Sam. - 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
