Re: git-svn set-tree bug

["Lars Hjemli" <lh@elementstorage.no>]

On 6/12/07, Eric Wong <normalperson@yhbt.net> 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