Felipe Contreras <felipe.contre...@gmail.com> writes:

> 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 for hg or bzr remote helpers, but
>> not applicable for git-remote-mediawiki.
> A centralized repository is a subset of decentralized workflows.

Yes, a strict subset. You can't keep a local copy of a remote repository
with a centralized VCS, so the way to write remote-helpers for DVCS does
not apply for centralized VCS.

> I don't know if a dumb push is the right thing to do here, but
> supposing it is, you can still report non-fast-forward errors:

That would be really complicated, as you would need to check whether
non-fast forward errors are serious. The check is done on pull, and the
reason the check should be disabled is dumb push.

> https://github.com/felipec/git/commit/0f7f0a223d710d29a4f1a03fc27348a8690d8a19
> https://github.com/felipec/git/commit/b67a8914bc1bb3ad23591875611165b84135aaf9

Err, don't they apply when pushing? In my case, the non-fast forward
occurs on pull.

> If it's too much hassle to find non-fast-forward situations by
> yourself, then perhaps it would make sense to update the remote
> namespace only when a certain feature has been flagged.

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.

Matthieu 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

Reply via email to