git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
BPBenoît Person <benoit.person@ensimag.fr>
Date
Jun 9, 2013, 12:35 UTC
Message-ID
<CAETqRCh9frekD8yiR0bE+WQ7b_et1th8p_LsqrL8NhPnC8yaow@mail.gmail.com>
In-Reply-To
<20130609060807.GA8906@sigill.intra.peff.net>
On 9 June 2013 08:08, Jeff King <peff@peff.net> wrote:
> 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.

Hum, so `git mw preview origin:page.mw` would just do the get request to the remote mediawiki, save it locally and - maybe - load it in the browser ? Is it really better than just opening the browser and typing the right URL ?

Currently, this URL is one click away when you have preview file loaded in a web browser.

Show 24 quoted lines
>> 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".
ok, thanks a lot.
Show 15 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.

The fact is, `git symbolic-ref HEAD` result would have to be parsed in order to extract the current branch name like I currently extract the remote name. So, is it really better than `git rev-parse --symbolic-full-name @{upstream}` ?

Show 10 quoted lines
>>   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.

Well, I thought that `git mw preview` could provide an interactive mode where, if the first search fails, it would find all the mediawiki remotes, and offers to the user a way to choose the remote ?

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
Previous: Jeff KingNext: Matthieu Moy
Message 8 of 14 in “git-remote-mediawiki: new tool to preview local changes without pushing”
  1. git-remote-mediawiki: new tool to preview local changes without pushingbenoit.person@ensimag.fr, Jun 7, 2013
  2. Matthieu MoyJun 8, 2013
  3. Jeff KingJun 9, 2013
  4. Jeff KingJun 9, 2013
  5. Matthieu MoyJun 9, 2013
  6. Benoît PersonJun 9, 2013
  7. Jeff KingJun 9, 2013
  8. Benoît PersonJun 9, 2013
  9. Matthieu MoyJun 9, 2013
  10. Jeff KingJun 9, 2013
  11. Benoît PersonJun 11, 2013
  12. Jeff KingJun 11, 2013
  13. Matthieu MoyJun 12, 2013
  14. Jeff KingJun 12, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.