Jeff King <peff@xxxxxxxx> writes: >> 1- Find the remote name of the current branch's upstream and check if it's a >> wiki one with its url (ie: mediawiki://) >> 2- Parse the content of the local file (given as argument) using the distant >> wiki's API. > > Makes sense. > >> 3- Retrieve the current page on the distant mediawiki. >> 4- Merge those those contents. > > I'm not sure what these steps are for. You are trying to preview not > just your local version, but pulling in any changes that have happened > upstream since the work you built on top of? 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". > 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. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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