On Tue, Feb 18, 2014 at 9:52 AM, Jeff King <peff@xxxxxxxx> wrote:
> 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.
>> [...]
>
> 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.
I agree that we want a more general (i.e. workflow-agnostic) term to
differentiate between "where we pull from", and "where we push to". As
such, "@{push}" should have a corresponding "@{pull}" (which I believe
should function as an alias of "@{upstream}"). [1]
...Johan
[1]: I don't think there is a reason not to reuse the "push"/"pull"
terminology for these concepts, but if there is, I guess we could
instead call them "@{source}"/"@{destination}", "@{src}/@{dst}", or
"@{from}/@{to}", or somesuch...
--
Johan Herland, <johan@xxxxxxxxxxx>
www.herland.net
--
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