Re: [PATCH 5/5] implement @{publish} shorthand
- From
Philip Oakley <philipoakley@iee.org>
- Date
- Jan 9, 2014, 08:31 UTC
- Message-ID
- <02F63E901C46405BAAEEFBC48870A7C2@PhilipOakley>
- In-Reply-To
- <20140108093716.GE15720@sigill.intra.peff.net>
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.
Much of the earlier discussion did appear to be as much a confusion over terminology as that of coding a suitable solution ro Ram's original forked-from issue.
I know it's been an issue I've had for some while http://thread.gmane.org/gmane.comp.version-control.git/194175/focus=195385
Philip