Re: Git fast-import : Warning duplicated ref: refs/remotes/origin/master

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 30, 2011, 20:13 UTC
Message-ID: <20110530201351.GB14427@elie>
In-Reply-To: <vpqzkm4gef2.fsf@bauges.imag.fr>

Hi,

Matthieu Moy wrote:

> Jonathan Nieder <jrnieder@gmail.com> writes:

Show 9 quoted lines

>>  sub mw_capabilities {
>>  #	print STDOUT "fetch\n";
>> +	print STDOUT "refspec refs/heads/*:refs/mediawiki/$remotename/*\n";
>
> Is this "mediawiki" comming from the URL (mediawiki::...), or is it just
> a convention you've set?
>
> We've tried with refspec refs/heads/*:refs/remotes/origin/*, but without
> success.

Yes, I stole the convention for the namespace name from the commit message to v1.7.0-rc0~62^2~19 (Allow helper to map private ref names into normal names, 2009-11-18).

Show 14 quoted lines

> Do I understand correctly that the "pull" is done in 3 stages:
>
> 1) import into refs/mediawiki/origin
>
> 2) fetch the imported ref into refs/remotes/origin
>
> 3) and merge as usual into the current branch
>
> ?
>
> If so, I don't understand why the distinction between 1) and 2) is
> necessary, and why not to fetch directly into refs/remotes/origin/. IOW,
> in which case is refs/remotes/origin/master different from
> refs/mediawiki/origin/master for example?

That's a good question. One answer is that fetching to elsewhere allows the transport machinery to take care of rejecting non-fast-forward fetches and pretty-printing the ref update information:

 From mediawiki::http://localhost/mediawiki
    479ee21..accd2c1  master     -> origin/master

I think in the long term, importing to no ref at all as Sverre suggested and teaching the transport-helper to do the ref update would make more sense.

Regards, Jonathan