Re: Separate default remotes for pulling and pushing

> Jeff King <peff@peff.net> writes:
> 
> >   4. Decentralized, you're a developer that publishes work via git. You
> >      call the upstream maintainer "origin", so fetches are convenient
> >      (and git does this for you at clone, after all). But pushing, even
> >      though you probably always push to the same central, does not have
> >      a convenient shorthand.
> >
> >      This is David's case (and mine, and I suspect some other git
> >      developers who do enough work that they want to make it publicly
> >      available via git, or even just have backups). It's also encouraged
> >      by sites like github, where you might clone the upstream's
> >      repository, but then pushes your changes up to a personal "fork"
> >      to let others see and merge them.
> 
> In a sense, this is what I do as well.  As you mentioned, I push to "ko"
> to publish, but when I "fetch" (or "pull") from "origin", I get the public
> copy I have at kernel.org like everybody else, and I do fetch every time
> after I push to "ko" to get the updated preformatted HTML and man page
> branches.

> While I see why some people might want to say "origin" for both in such a
> set-up (when they do not push to multiple places like I do), I have a
> feeling that it is a misguided wish that would make themselves unnecessary
> confused than they already are, especially if the repositories used for
> pushing and fetching are in reality different repositories (one good
> example why it would be confusing is how remote tracking branches are
> updated).