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

From: Jeff King <peff@peff.net>
Date: Feb 18, 2014, 08:52 UTC
Message-ID: <20140218085224.GB2692@sigill.intra.peff.net>
In-Reply-To: <9D08338A41454F778D03FB2E9F4B7DD1@PhilipOakley>

On Sat, Feb 15, 2014 at 11:50:10AM -0000, Philip Oakley wrote:

Show 15 quoted lines

> >>> This patch introduces the <branch>@{publish} shorthand (or
> >>> "@{pu}" to be even shorter).
> 
> Just to say that I'm not sure that "publish" is the best word for
> this concept.
> 
> To my mind something is published when some form of editorial
> oversight has been applied to the works. Such an understanding would
> better match the 'upstream' concept (e.g. $gmane/240230 jch/9Jan14).
> This should be distinguished from 'self-publishing', and again from
> 'vanity-publishing'.
> 
> In terms of the triangular work-flow such a 'publish' repo is
> somewhere between a vanity publishing, and self publishing (depending
> on the level of code cleanliness;-)

I would much rather have a name that describes what the thing _is_, then how it is meant to be used. The concept of @{publish} is a shorthand for "where would I push if I typed git push on this branch". In a non-triangular workflow, that means sharing your commits with others on the main branch. In a triangular workflow, it means sharing your commits with a publishing point so that others can see them. If your default push goes to a backup repo, it does not mean publishing at all, but rather syncing the backup.

So I do not think any one word can describe all of those use cases; they are orthogonal to each other, and it depends on your workflow.

In that sense, "publish" is not the best word, either, as it describes only the first two, but not the third case (and those are just examples; there may be other setups beyond that, even).

Perhaps "@{push}" would be the most direct word.

-Peff