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

From: Jeff King <peff@peff.net>
Date: Jan 9, 2014, 22:03 UTC
Message-ID: <20140109220351.GD32069@sigill.intra.peff.net>
In-Reply-To: <02F63E901C46405BAAEEFBC48870A7C2@PhilipOakley>

On Thu, Jan 09, 2014 at 08:39:44AM -0000, Philip Oakley wrote:

Show 19 quoted lines

> From: "Jeff King" <peff@peff.net>
> Sent: Wednesday, January 08, 2014 9:37 AM
> >In a triangular workflow, you may have a distinct
> >@{upstream} that you pull changes from, but publish by
> >default (if you typed "git push") to a different remote (or
> >a different branch on the remote).
> 
> One of the broader issues is the lack of _documenation_ about what
> the 'normal' naming convention is for the uspstream remote.
> Especially the implicit convention used within our documentation (and
> workflow).
> 
> This is especially true for github users who will normally fork a
> repo of interest and then clone it from their own copy/fork. This
> means that the 'origin' remote is _not_ the upstream. See
> https://help.github.com/articles/fork-a-repo In my case 'origin' is
> my publish repo (as suggested by Github) while 'junio' is the
> upstream (as do some others). There are similar results from the
> likes of Stackoverflow.

Sure, and I have done the same thing (though I tend to clone from the other person as "origin", and only fork my own repo when I am ready to push). But it shouldn't matter, should it? The whole point of the upstream config is that "git checkout -b topic junio/master" does the right thing, without caring about your naming convention.

So I'm not sure what you think should be said (or where). Telling me in patch form is preferred. :)

-Peff