Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html