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

From: Jeff King <peff@peff.net>
Date: Jun 9, 2013, 06:08 UTC
Message-ID: <20130609060807.GA8906@sigill.intra.peff.net>
In-Reply-To: <1370641831-9115-1-git-send-email-benoit.person@ensimag.fr>

On Fri, Jun 07, 2013 at 11:50:31PM +0200, benoit.person@ensimag.fr wrote:

> The #7 issue on git-mediawiki's issue tracker [1] states that the ability to
> preview content without pushing would be a nice thing to have.

Sounds like a useful goal.

Show 5 quoted lines

> The default behaviour for the `preview` subcommand is:
> 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?

It seems like that is a separate, orthogonal issue, and git would be the right place to do that merge. IOW, as a user, your workflow would be something like:

  1. git fetch, pulling down the latest copy from the server

  2. make your changes on top

  3. use this command to preview your changes

  4. use git fetch to check whether anything else happened on the
     server.

       a. If not, go ahead and push.

       b. If upstream changed, use "git diff" to inspect the changes to
          the wiki source. Merge or rebase your changes with respect to
          what's on the server. Goto step 3 to make sure they look good.

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.

> It works but a couple of points trouble me: 
> 1-  I had to copy two functions from `git-remote-mediawiki.perl`, I don't 
>     really know how we could "factorize" those things ? I don't think it makes 
>     much sense to create a package just for them ?

You could make a Git::MediaWiki.pm module, but installing that would significantly complicate the build procedure, and potentially be annoying for users. One trick I have done in the past is to concatenate bits of perl script together in the Makefile, like this:

  foo: common.pl foo.pl
          { \
            echo '$(PERL_PATH_SQ)' && \
            for i in $^; do \
              echo "#line 1 $src" && \
                cat $src \
            done \
          } >$@+
          mv $@+ $@

That would conflict a bit with the way we chain to git's Makefile, though. I suspect you could do something complicated like build "foo.pl" from "common.pl" and "foo-main.pl", then chain to git's Makefile to build "foo" from "foo.pl".

Show 5 quoted lines

> 2-  The current behavior is to crash if the current branch do not have an
>     upstream branch on a valid mediawiki remote. To find that specific remote, 
>     it runs `git rev-parse --symbolic-full-name @{upstream}` which will return 
>     something like `/refs/remotes/$remote_name/master`.
>   2a-  maybe there is a better way to find that remote name ?

If you just care about the remote name and not the name of the local branch, you can just ask for

  my $curr_branch = `git symbolic-ref HEAD`;
  my $remote = `git config "branch.$curr_branch.remote"`;
  my $url = `git config "remote.$remote.url"`;

Of course you would want some error checks and probably some chomp()s in there, too.

>   2b-  would it be useful to add a fallback if that search fails ? searching 
>        for a valid mediawiki remote url in all the remotes returned by 
>        `git remote` for instance ?

That is probably OK as long as there is only one such remote, and it would help the case where you have branched off of a local branch (so your upstream remote is "."). If there are two mediawiki remotes, though, it would make sense to simply fail, as you don't know which to use. But I'd expect the common case by far to be that you simply have one such remote.

-Peff