Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing

["Benoît Person" <benoit.person@ensimag.fr>]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Same question here. I'd expect "git mw preview" in a mediawiki workflow
> to do what "pdflatex foo && evince foo.pdf" do in a latex workflow: see
> in rendered form what I've been doing.
>
> In a latex flow, if I want to see how my local changes merge with the
> remote ones, I do "git merge && pdflatex", and I'd do the same with "git
> mw".

In fact, I should not have used "merge" to describe how the two contents
(page template + new parsed content) are combined together. For
now, the code simply replaces the template page's text content (the one
retrieved from the remote) with the new one. It does not really care if
the remote has changes or not. (And, to be honest, I did not thought
about that issue ;) ).

But, like both of you said : in a typical workflow, the merging would be
left to the user so the current behavior is fine I think ?

>> I also wonder if it would be useful to be able to specify not only files
>> in the filesystem, but also arbitrary blobs. So in 4b above, you could
>> "git mw preview origin:page.mw" to see the rendered version of what
>> upstream has done.
> Next step could even be "git mw diff $from $to", using the wiki to
> render the diff. Not a priority, but could be funny.

I searched in the Mediawiki API if there was a way to diff from a stored
revision and raw text content but I've found nothing :/ . We could make
a little "hack" to do that by saving as a new revision the local content,
and use the "DeleteRevision"-thingy from Mediawiki [1] to hide this
useless revision but it would floods the remote DB and usually users
to not have the permission to use that tool. So, for now I would say
it's a no-go :/ .

[1] http://www.mediawiki.org/wiki/Manual:RevisionDelete

Benoit Person

> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html