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