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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 24, 2014, 00:16 UTC
Message-ID: <xmqqob32s08p.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140108093716.GE15720@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 20 quoted lines

> 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'.

    This patch introduces the <branch>@{publish} shorthand that
    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
    
    With this, foo@{upstream} and foo@{publish} would be origin/master
    and github/foo, respectively (assuming that "git fetch github" is
    configured to use refs/remotes/github/* remote-tracking branches).

> The implementation feels weird, like the "where do we push to" code
> should be factored out from somewhere else. I think what we're doing
> here is not _wrong_, but I don't like repeating what "git push" is doing
> elsewhere. And I just punt on "simple" as a result. :)

I think we can polish that in-tree.

Thanks.