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