Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> On Wed, Aug 21, 2013 at 4:36 PM, Matthieu Moy
> <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
>> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>>
>>> On Tue, Aug 13, 2013 at 8:31 AM, Matthieu Moy <Matthieu.Moy@xxxxxxx> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html