Re: [PATCH 5/5] implement @{publish} shorthand
- From
Johan Herland <johan@herland.net>
- Date
- Feb 18, 2014, 13:10 UTC
- Message-ID
- <CALKQrgeH+xOqjOv8Z0nnBrmE0=L8GMWn+ewiN+mWBkO5dOvtvA@mail.gmail.com>
- In-Reply-To
- <20140218085224.GB2692@sigill.intra.peff.net>
On Tue, Feb 18, 2014 at 9:52 AM, Jeff King <peff@peff.net> wrote:
Show 25 quoted lines
> 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@herland.net> www.herland.net