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

Jonathan Nieder [off-list ref] writes:

Jérémie NIKAES wrote:

quoted

No, I actually still have the problem. The version commited on github
is pulling revisions straight to refs/heads/master which is gross
After discussing this matter with our teacher Matthieu Moy, I wanted
to change this to refs/remotes/origin/master but then this warning
gets thrown.

The following fixes it for me.

It seems it does, thanks!

clone does not give the warning anymore, and incremental pull work.

 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.

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?

Thanks,

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

2011/5/30 Matthieu Moy [off-list ref]:

Jonathan Nieder [off-list ref] writes:

quoted

Jérémie NIKAES wrote:

quoted

No, I actually still have the problem. The version commited on github
is pulling revisions straight to refs/heads/master which is gross
After discussing this matter with our teacher Matthieu Moy, I wanted
to change this to refs/remotes/origin/master but then this warning
gets thrown.

The following fixes it for me.

It seems it does, thanks!

clone does not give the warning anymore, and incremental pull work.

Yes ! It definitely does ! Works like a charm.

quoted

 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.

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?

Thanks,

We just committed this change to our master branch on github. We
actually have the same questions as Matthieu. We don't really
understand why we have to use another ref to make it work.

Huge thanks to you,

-- 
Jérémie Nikaes

Hi,

Matthieu Moy wrote:

Jonathan Nieder [off-list ref] writes:

quoted

 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).

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

Matthieu Moy wrote:

quoted

Jonathan Nieder [off-list ref] writes:

quoted

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.

Well yes that would indeed make more sense. It feels weird to have to
do it like this.
Anyways, thanks a lot again for your help, a rfc patch should come
relatively quickly with the project in its current state.

Regards,
-- 
Jérémie Nikaes

Heya,

On Mon, May 30, 2011 at 15:32, Jérémie NIKAES [off-list ref] wrote:

Well yes that would indeed make more sense. It feels weird to have to
do it like this.

The patch series I was referring to can be found at [0].

[0] http://thread.gmane.org/gmane.comp.version-control.git/157860/focus=157864

-- 
Cheers,

Sverre Rabbelier