Re: GSOC remote-svn

Florian Achleitner [off-list ref] writes:

But my remote-helper didn't advertise the refspec capability, so transport-
helper assumed it imports to refs/heads/master, which is the default import 
refspec.

The man page for git-remote-helpers says:

refspec <refspec>
    [...] It is recommended that all importers providing the import
    capability use this.

I'm not sure I fully understand the rationale, but one difference
between refs/<remote name>/* and refs/remotes/<remote name> is that
refs/remotes/ is automatically updated by Git on push, while the private
namespace isn't (it only receives updates when importing).

I played a bit with that it git-remote-mediawiki. There's a
configuration variable mediawiki.dumbPush that controls what "push"
does. It can either export the local history without touching local
metadata (and then, it is expected that the user does a "git pull
--rebase" right after to re-import the history), or update the local
metadata (private ref, and notes that keep the <local commit> <->
<remote revision number> map), so that the next "git pull" says
"Already up to date.".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Matthieu Moy wrote:

The man page for git-remote-helpers says:

refspec <refspec>
    [...] It is recommended that all importers providing the import
    capability use this.

I'm not sure I fully understand the rationale, but one difference
between refs/<remote name>/* and refs/remotes/<remote name> is that
refs/remotes/ is automatically updated by Git on push, while the private
namespace isn't (it only receives updates when importing).

It's mostly to allow "git fetch" to avoid non fast-forward updates
unless -f was used or the refspec starts with +.

I always liked the idea of tweaking the fast-import stream format to
allow the import to happen on no branch at all since it would avoid
all these questions.  Maybe another day.

Thanks,
Jonathan