Re: native-git-svn: A Summer of Code 2010 proposal

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Mar 22, 2010, 03:49 UTC
Message-ID: <f3271551003212049r1139d6b4x279c6803cc4c7fe2@mail.gmail.com>
In-Reply-To: <201003220341.38918.chriscool@tuxfamily.org>

> Don't know about importer modes, but in native connection mode it is
> possible to avoid calling or linking to git in any way (been there, done
> that).

Show 7 quoted lines

> Mostly, except that I think it should be possible to avoid having
> git-remote-svn actually link to the git core, because the git core should
> be taking care of everything git-specific for you. Of course, the git core
> also provides a bunch of useful C library code that you may want to use,
> such as a nice string buffer implementation, so you may want to link to
> git even if you don't actually need it, if licenses are suitable and it
> would be convenient.

As of this point, I'm undecided about which parts of Git Core to link to, if at all. I'll try to avoid linking, but I'll do whatever is most convenient within the bounds of the license as I write the remote helper.

Show 7 quoted lines

> I solved this problem you mention by rebasing in both directions onto
> detached HEADs and exporting the result, meaning that the history is
> permanently diverged from a DAG standpoint.  Of course, over time, the
> rebase would become increasingly messy and horrible, so I created a
> couple of placeholder refs which are updated after the import/export is
> finished.  These mark the last time it was done, and allow you only to
> attempt to apply the commits which are new on each side.

Ah. Could you please post a link to your code?

> Because it's much better for everyone at the end of the GSoC if only half of
> the project is finished but merged, rather than if all the project is "finished"
> but nothing can be merged.

Right. I'll merge the whole thing in 3-4 phases then.

-- Ram