From: "Michael Haggerty" <mhagger@xxxxxxxxxxxx>
On 04/26/2014 01:19 AM, 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.
[...]
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.
Is it too late and/or impossible to think of a different name for
either
"push" or "publish" so that their single-letter abbreviations don't
coincide?
I'd initially grated against the 'publish' name. I didn't feel as that
what I'd be pushing would be publish-worthy in the sense that when a
book is published it's also edited before release, unless
vanity-published.
For a basic triangular flow where the user is simply using a remote
server as a sort of backup (e.g. github) then I thought that "self" may
a suitable name, though it does feel too much of a specific case.
Part of the problem is that the DVCS style is new so there isn't a good
word for 'the other side of the river', that's neither upstream, nor
downstream, but a ferry crossing to another safe harbour.
I'm now sort of OK with push and publish being the same thing.
--
Philip
£0.02p
--
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