Jeff King <p...@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 <p...@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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to