Re: GSOC Proposal draft: git-remote-svn

[Andrew Sayers <andrew-git@pileofstuff.org>]

On 02/04/12 23:29, Jonathan Nieder wrote:
> Hi Andrew,
> 
> Andrew Sayers wrote:
>> On 02/04/12 09:30, Florian Achleitner wrote:
> 
>>> The remote helper has to convert the foreign protocol and data (svn) to the 
>>> git-fast-import format.
>>
>> As discussed on IRC, I'd like to see some discussion of solutions that
>> use plumbing directly (e.g. git-commit-tree) if you choose to focus on
>> branch import.
> 
> Do you mean that fast-import is not a plumbing command?

Sorry, that wasn't clear.  I meant commands that just expose a single
primitive bit of functionality (like git-commit-tree) instead of those
that present an abstract interface to the whole git machinery (like
git-fast-import).  I'm not sure what the right word for that would be?

I agree it's possible to use fast-import for this problem, but it seems
like it's redundant after svn-fe has already loaded everything into git.
 For example, if svn-fe loaded three revisions into the master branch,
you could create a trunk branch by doing something like:

COMMIT=$( git show -s --pretty=%b master^^ | \
          git commit-tree master^^:trunk )
COMMIT=$( git show -s --pretty=%b master^ | \
          git commit-tree master^:trunk -p $COMMIT )
COMMIT=$( git show -s --pretty=%b master | \
          git commit-tree master:trunk -p $COMMIT )
echo $COMMIT > .git/refs/heads/foo

The point I was making in IRC was that (so far as I understand)
fast-import doesn't let you pass trees around in this way, but instead
requires you to transmit the contents of all the changed files.

The code above could of course be achieved more easily with
git-filter-branch, or achieved more efficiently with a custom bit of C.
 I suggested discussing the problem in terms of single-purpose commands
because it strikes me as about the right level to expose the
architectural questions without getting bogged down in detail.

	- Andrew