On 6/12/07, Eric Wong <normalperson@xxxxxxxx> wrote:
If dcommit detects a merge commit when doing rev-list When looking at commit objects, is it safe to assume that the first parent is always the "mainline" and that parents after it are the ones to merge from? So if I saw: commit $X parent $A parent $B I'd basically do: reset --hard $A merge --squash $B And resulting in $C which would have the same tree as $X, then, when dcommit-ting, $D would be created with two parents: $D~1 (svn), $B (git), but not $A Rewritten history: $A => $D~1 $X => $D (HEAD revision in SVN) $X and $A are now discarded and gc-able. Of course, since I already have the result of "merge --squash $B" in $X, I could just rewrite $X with a single parent (call it $X'), dcommit, and then give $D ($D~1 and $B) as parents. Avoiding the nastiness of set-tree
Would it be possible to keep the 'local commit' $X and change the mapping in .rev_db to point at $X instead of $D? This would of course require a matching TREE-ID + noMetadata=1. I've been tempted to try to implement this, but my perl-skills are sadly non-existent. If this is possible it would make my day-job interaction with svn a much more pleasant experience: push/pull between git repos would 'just work' (without -f). And if "follow left parent" also works out, I (and our 'releasemaster') can finally do all merging in git (without --squash) and preserve the DAG. Ahh, that would be great... -- larsh - 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
