Re: [PATCH 5/5] implement @{publish} shorthand

From: Jeff King <peff@peff.net>
Date: Jan 24, 2014, 21:35 UTC
Message-ID: <20140124213521.GA26602@sigill.intra.peff.net>
In-Reply-To: <xmqqob32s08p.fsf@gitster.dls.corp.google.com>

On Thu, Jan 23, 2014 at 04:16:06PM -0800, Junio C Hamano wrote:

Show 27 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > In a triangular workflow, you may have a distinct
> > @{upstream} that you pull changes from, but publish by
> > default (if you typed "git push") to a different remote (or
> > a different branch on the remote). It may sometimes be
> > useful to be able to quickly refer to that publishing point
> > (e.g., to see which changes you have that have not yet been
> > published).
> >
> > This patch introduces the <branch>@{publish} shorthand (or
> > "@{pu}" to be even shorter). It refers to the tracking
> > branch of the remote branch to which you would push if you
> > were to push the named branch. That's a mouthful to explain,
> > so here's an example:
> >
> >   $ git checkout -b foo origin/master
> >   $ git config remote.pushdefault github
> >   $ git push
> >
> > Signed-off-by: Jeff King <peff@peff.net>
> > ---
> 
> As there is no @{pu} in publish_mark() as far as I can see, and also
> I found it is a bit unclear what the example in the last paragraph
> wants to illustrate, I'll reword the above as the following before
> merging it to 'next'.

Yeah, I think the @{pu} was just a silly omission from the code, though I agree after our discussion that we should just stick with "@{publish}" for now.

I am not sure why I said "git push" at the end. I would have thought that:

  $ git rev-parse --symbolic-full-name @{publish}
  refs/remotes/github/foo

would have been the right command to demonstrate. The text you suggested is fine, though I think you can simply drop the "git push", as it does not add anything.

As far as merging it to 'next', I had not really intended it to go that far. :) It was more for Ram to use as a base. I find some of the refactoring questionable, including:

  1. The meaning of branch->pushremote is subtly different from that of
     branch->remote. Ram's followup refactoring did a better job of
     that (but he is missing the patches on top to finish out the
     feature).

  2. We are duplicating the "where to push" logic here. That should
     probably be factored out so that "git push" and "@{publish}" use
     the same logic.

And of course there are no tests or documentation. It might work, though.

I don't mind if you want to merge it and do more work in-tree, but I do not think it should graduate as-is. And you may want check from Ram that he is not in the middle of his own version based on the patches he sent earlier, as reworking them on top of mine would probably just be needless extra work.

Are you planning on having request-pull use @{publish} as a default? I saw you cc'd me on that thread, but I didn't have any opinion besides "sounds like you could use it here".

-Peff