Felipe Contreras felipe.contre...@gmail.com writes:
On Mon, Aug 26, 2013 at 4:16 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Ideally, it
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
git-remote-mediawiki is kind of a special case, as the remote side uses
a very different data model, hence it can make sense to export+reimport
to get locally what the remote side received.
Hmm, I am
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
How would I do that? The update to the remote namespace is done by Git,
not by the remote-helper.
OK, I'm now convinced that my solution is the right one. The
alternatives are far more complex and I
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
How would I do that? The update to the remote namespace is done by Git,
not by the remote-helper.
OK, I'm now convinced that my solution is the
Matthieu Moy matthieu@grenoble-inp.fr writes:
Not updating was the default until 664059fb62 (i.e. until 1.8.4), so the
default already changed once. I tend to agree with Felipe that doing the
update by default makes sense.
OK. Thanks.
git-remote-mediawiki is kind of a special case, as
On Mon, Aug 26, 2013 at 4:16 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
How would I do that? The update to the remote namespace is done by
Matthieu Moy matthieu@grenoble-inp.fr writes:
How would I do that? The update to the remote namespace is done by Git,
not by the remote-helper.
OK, I'm now convinced that my solution is the right one. The
alternatives are far more complex and I still fail to see the benefits.
Sounds
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
On Fri, Aug 23, 2013 at 3:25 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
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
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
On Tue, Aug 13, 2013 at 8:31 AM, Matthieu Moy matthieu@imag.fr wrote:
Git-mediawiki's dumb push sends the local revisions to the remote wiki,
but does not update the local metadata to reflect the push (hence, the
next pull will have to re-import the exported revisions).
The previous
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
Git-mediawiki's dumb push sends the local revisions to the remote wiki,
but does not update the local metadata to reflect the push (hence, the
next pull will have to re-import the exported revisions).
The previous implementation was simply omitting the update to the private
ref after a dumb push.
13 matches
Mail list logo
