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

[Jeff King <peff@peff.net>]

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

> 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