Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Felipe Contreras <felipe.contreras@gmail.com>]

Jeff King wrote:
> On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:

> > * fc/publish-vs-upstream (2014-04-21) 8 commits
> >  - sha1_name: add support for @{publish} marks
> >  - sha1_name: simplify track finding
> >  - sha1_name: cleanup interpret_branch_name()
> >  - branch: display publish branch
> >  - push: add --set-publish option
> >  - branch: add --set-publish-to option
> >  - Add concept of 'publish' branch
> >  - t5516 (fetch-push): fix test restoration
> > 
> >  Add branch@{publish}; it seems that this is somewhat different from
> >  Ram and Peff started working on.  There were many discussion
> >  messages going back and forth but it does not appear that the
> >  design issues have been worked out among participants yet.
> 
> If you are waiting on me, I do not have much else to say on this topic.
> @{publish} as specified by Felipe is not useful to me, and I would
> continue to pursue @{push} separately as "the remote-tracking branch of
> where you would push to". I think there is room for both concepts.
> 
> As for the patches themselves, I have not reviewed them carefully, and
> would prefer not to. As I mentioned before, though, I would prefer the
> short "@{p}" not be taken for @{publish} until it has proven itself.

Presumably you want to save it for @{push}. While I'm not against to having
just @{publish} for now, I'm farily certain most people would be using
@{publish} and not @{push}, as that's what `git branch -v` would show, and it
would be closely similar to @{upstream}. Therefore it would make sense to use
@{p} for @{publish}

-- 
Felipe Contreras