Re: [RFC/PATCH] git-remote-mediawiki: reset private ref after non-dumb push

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Wed, Aug 21, 2013 at 4:36 PM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> On Tue, Aug 13, 2013 at 8:31 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>>>
>>>> Felipe: Is this the right fix for git-remote-mediawiki? Any better idea?
>>>
>>> Why not keep track of the revisions yourself? You can have file where
>>> you store which was the last revision that was fetched.
>>
>> I don't really understand the point of the "private namespace" anymore I
>> guess. Why do we have both refs/remotes/$remote and
>> refs/$foreign_vcs/$remote, if they are always kept in sync?
>
> They are not always in sync; if a push fails, the private namespace is
> not updated.
[...]
> As I said, they are not exactly the same. It is possible refs/remotes
> point to a mercurial revision on the remote server, and refs/hg points
> to a mercurial revision on the local internal repository, and they are
> not the same.

This is assuming you follow the scheme

  git -> local repo for other vcs -> remote repo for other vcs

which itself more or less assumes that the other VCS is a decentralized
VCS. I understand this is a good idea for hg or bzr remote helpers, but
not applicable for git-remote-mediawiki.

I find this very unclear in the doc. How about adding something like
this in the "'refspec' <refspec>::" part?

--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -176,6 +176,12 @@ applicable refspec takes precedence.  The left-hand of refspecs
 advertised with this capability must cover all refs reported by
 the list command.  If no 'refspec' capability is advertised,
 there is an implied `refspec *:*`.
++
+When writing remote-helpers for decentralized version control
+systems, it is advised to keep a local copy of the repository to
+interact with, and to let the private namespace refs point to this
+local repository, while the refs/remotes namespace is used to track
+the remote repository.
 
 'bidi-import'::
        This modifies the 'import' capability.

So, now, I understand the point of the private namespace in the case of
DVCS, but still note really for interactions with centralized VCS.

Back to my original problem: the point of dumb push is to make sure the
next import will re-import the pushed revisions. if I use something
other than the private namespace to keep track of the last imported,
then I'll need to do a non-fast forward update to the private ref. I
could do that by sending "feature force\n" it the beginning of the
fast-import stream when importing, but that loses one safety feature
(e.g. I detected the breakage thanks to the non-fast forward error
message, while the tests incorrectly pass if I enable "force").

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