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

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