Re: GSoC 2010

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Feb 12, 2010, 19:16 UTC
Message-ID: <alpine.LNX.2.00.1002121158430.14365@iabervon.org>
In-Reply-To: <fabb9a1e1002120841o71651f82h782eab46206df402@mail.gmail.com>

On Fri, 12 Feb 2010, Sverre Rabbelier wrote:

Show 8 quoted lines

> Heya,
> 
> On Fri, Feb 12, 2010 at 17:10, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > Also note that the current helper protocol is definitely insufficient to
> > replace git-svn ('export' isn't actually specified, although I think
> > everyone who guesses how it works guesses the same thing),
> 
> I've finally started implementing this yesterday.

Great.

Show 10 quoted lines

> > and the
> > transport code needs to be extended to handle the "dcommit" situation
> > (when you push a commit, the state that you see on the remote changes
> > based on the semantics of what you sent, but it does not change to have
> > the same hash as what you pushed).
> 
> So basically what you want to do is after you push, automagically do a
> 'git reset --hard @{u}'? That could be handled by a specific response
> from the helper to the 'export'/'push' command, perhaps it could list
> which refs need to be updated?

I think that 'export' will always have this effect, because the export/reimport roundtrip is practically never going to be exact with a remote system that isn't actually git (and the state that you see the remote as having after a successful push should match what you see if you were to clone again). People have wanted to have the remote server getting a push able to make changes like this as well, and so far we've resisted doing it, because it starts causing problems.

I'm not sure what it should do, and I'm not terribly happy about any of the obvious choices, but it does have to do something to be able to replace "git svn dcommit".

	-Daniel
*This .sig left intentionally blank*