From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>, git@vger.kernel.org
Subject: Re: [RFC/PATCH] git-remote-mediawiki: reset private ref after non-dumb push
Date: Mon, 26 Aug 2013 10:48:50 +0200 [thread overview]
Message-ID: <vpqhaeckfbh.fsf@anie.imag.fr> (raw)
In-Reply-To: xmqq61uumnsz.fsf@gitster.dls.corp.google.com
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@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 like a plan, even though it smells like the "update is done
> by Git" that does not have any way to opt-out may be the real design
> mistake and your "solution" is a work-around to that.
>
> Would it be a possibility to make it tunable, perhaps by introducing
> a capability on the remote-interface side that allows you to tell it
> not to mess with the remote namespace?
Ideally, it would be possible to ask for a non-update without a fatal
error on old Git versions, but this is not possible (hence, my fix is
the "portable" one, that works on Git 1.8.4).
But that's probably the best we can do now.
> If we were doing this from scratch, I would suspect that we would have
> made the capability work the other way around (Git does not do the
> update by default, but helpers c an ask Git to do so).
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.
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. But when interacting with
something closer to Git (bzr, hg, ...), the mapping should be close to
1-1 and re-importing wouldn't make sense.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2013-08-26 8:49 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
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 [this message]
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=vpqhaeckfbh.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp.fr \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).