From: Junio C Hamano <gitster@pobox.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Jul 2013, #05; Fri, 12)
Date: Mon, 15 Jul 2013 12:32:38 -0700 [thread overview]
Message-ID: <7vy597aaax.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <vpqd2qkgr19.fsf@anie.imag.fr> (Matthieu Moy's message of "Mon, 15 Jul 2013 10:34:42 +0200")
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * bp/mediawiki-preview (2013-07-08) 7 commits
>> (merged to 'next' on 2013-07-12 at 870890a)
>> + git-remote-mediawiki: add preview subcommand into git mw
>> + git-remote-mediawiki: add git-mw command
>> + git-remote-mediawiki: factoring code between git-remote-mediawiki and Git::Mediawiki
>> + git-remote-mediawiki: update tests to run with the new bin-wrapper
>> + git-remote-mediawiki: add a git bin-wrapper for developement
>> + wrap-for-bin: make bin-wrappers chainable
>> + git-remote-mediawiki: introduction of Git::Mediawiki.pm
>>
>> Add a command to allow previewing the contents locally before
>> pushing it out, when working with a MediaWiki remote.
>>
>> I personally do not think this belongs to Git. If you are working
>> on a set of AsciiDoc source files, you sure do want to locally
>> format to preview what you will be pushing out, and if you are
>> working on a set of C or Java source files, you do want to test it
>> before pushing it out, too. That kind of thing belongs to your
>> build script, not to your SCM.
>
> There's one big difference: when you use AsciiDoc/C/Java/... your build
> system works locally. "git mw preview" uses the remote wiki to do the
> rendering.
>
> It doesn't do so with the remote-helper interface, but uses
> the same remote and same configuration as the remote-helper, and it
> shares some code with it. It seems logical to let it leave next to the
> remote-helper (but clearly in contrib/, not in the core Git).
Hmph, I do not see it fundamentally different from using distcc to
compile not locally.
Your build infrastructure can (ab)use the configuration mechanism
for Git to store necessary information to find out what workers are
willing to help your compilation. The mediawiki-preview program is
talking over MediaWiki protocol, and it may reuse the same
credential information stored in the config to talk to the same
MediaWiki installation in connect_maybe() and sending the updated
page contents to ask it to render, but I do not see a fundamental
reason why the worker has to be the same MediaWiki installation as
your "repository".
So, no, I do not see a "big" difference there.
That does not mean I'd retract what I already said in the previous
issue of "What's cooking", i.e.
>> But I'll let it pass, as this is only a contrib/ thing.
;-)
prev parent reply other threads:[~2013-07-15 19:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-12 22:53 What's cooking in git.git (Jul 2013, #05; Fri, 12) Junio C Hamano
2013-07-15 8:34 ` Matthieu Moy
2013-07-15 19:32 ` Junio C Hamano [this message]
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=7vy597aaax.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
/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).