On Sat, Feb 15, 2014 at 11:50:10AM -0000, Philip Oakley wrote:
> >>> 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
--
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