From: Matthieu Moy <Matthieu.Moy@grenoble-inp•fr>
To: Felipe Contreras <felipe.contreras@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: [RFC/PATCH] git-remote-mediawiki: reset private ref after non-dumb push
Date: Fri, 23 Aug 2013 10:25:29 +0200 [thread overview]
Message-ID: <vpqbo4o3jba.fsf@anie.imag.fr> (raw)
In-Reply-To: <CAMP44s3jh4iEbgONaEU0WSCc5YiGYoK8edcgWU6qmUARToVRuw@mail.gmail.com> (Felipe Contreras's message of "Thu, 22 Aug 2013 12:20:42 -0500")
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/
next prev parent reply other threads:[~2013-08-23 8:25 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-13 13:31 [RFC/PATCH] git-remote-mediawiki: reset private ref after non-dumb push Matthieu Moy
2013-08-21 19:48 ` Felipe Contreras
2013-08-21 21:36 ` Matthieu Moy
2013-08-22 17:20 ` Felipe Contreras
2013-08-23 8:25 ` Matthieu Moy [this message]
2013-08-23 19:52 ` Felipe Contreras
2013-08-24 7:46 ` Matthieu Moy
2013-08-25 3:50 ` Junio C Hamano
2013-08-26 8:48 ` Matthieu Moy
2013-08-26 9:16 ` Matthieu Moy
2013-08-26 16:28 ` Felipe Contreras
2013-08-27 7:25 ` Matthieu Moy
2013-08-29 18:58 ` [PATCH 1/4] git-remote-mediawiki: add test and check Makefile targets Matthieu Moy
2013-08-29 18:58 ` [PATCH 2/4] transport-helper: add dont-update-private capability Matthieu Moy
2013-08-29 19:14 ` Felipe Contreras
2013-09-02 7:19 ` [PATCH v2 1/4] git-remote-mediawiki: add test and check Makefile targets Matthieu Moy
2013-09-02 7:19 ` [PATCH v2 2/4] transport-helper: add no-private-update capability Matthieu Moy
2013-09-02 7:28 ` Felipe Contreras
2013-09-02 7:41 ` [PATCH v3 2/4] transport-helper: add dont-update-private capability Matthieu Moy
2013-09-03 15:45 ` [PATCH v4 2/4] transport-helper: add no-private-update capability Matthieu Moy
2013-09-02 7:19 ` [PATCH v2 3/4] git-remote-mediawiki: use no-private-update capability on dumb push Matthieu Moy
2013-09-02 7:19 ` [PATCH v2 4/4] git-remote-mediawiki: no need to update private ref in non-dumb push Matthieu Moy
2013-08-29 18:58 ` [PATCH 3/4] git-remote-mediawiki: use dont-update-private capability on dumb push Matthieu Moy
2013-08-29 19:08 ` Junio C Hamano
2013-08-29 18:58 ` [PATCH 4/4] git-remote-mediawiki: no need to update private ref in non-dumb push Matthieu Moy
2013-08-29 19:09 ` Junio C Hamano
2013-08-26 16:26 ` [RFC/PATCH] git-remote-mediawiki: reset private ref after " Junio C Hamano
2013-08-27 7:28 ` Matthieu Moy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpqbo4o3jba.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp$(echo .)fr \
--cc=felipe.contreras@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox