Thread (6 messages) flat view 6 messages, 2 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 22:57:38

On Sun, Jun 09, 2013 at 02:35:45PM +0200, Benoît Person wrote:
On 9 June 2013 08:08, Jeff King [off-list ref] wrote:
quoted
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 ?
Not really, but when you start doing "origin^:page.mw", it may make more
of a difference.
quoted
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}` ?
It is, because it is not strictly true that an upstream of
"refs/remotes/foo/*" is for the remote "foo" (though in 99% of cases, it
is). To find the upstream, git looks at branch.$curr_branch.remote, then
calculates the upstream based on the fetch refspecs. Then you try to
undo that by converting it back from the right-hand side of the fetch
refspec into a remote name. It would be much easier to just look at the
config. :)

And yes, you do need the short name of the branch from HEAD, not the
full refname. You can use "git symbolic-ref --short" for that. You also
should check that it returns something useful (i.e., that we are not on
a detached HEAD).
quoted
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 ?
That's fine; just as long as we do not silently produce output from an
unknown source when there is ambiguity.

You can do an interactive selection, or even just say something like:

  There are multiple mediawiki remotes, and I do not know which one you
  want to use for your preview. Which of:

    remote1
    remote2

  did you mean? Try using the "-r" option to specify the remote.

and then let the user repeat their command with the "-r" option using
shell history. That saves you from having to write an interactive
component, and teaches the user how to script it.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help