Re: Separate default remotes for pulling and pushing

From: Junio C Hamano <gitster@pobox.com>
Date: May 9, 2011, 16:45 UTC
Message-ID: <7viptjq0ua.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110509081708.GA5871@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 12 quoted lines

>   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.

I never felt it awkward that my fetch says "origin" and my push says "ko". Even though I imagine that I could smash them together into a single "origin", it would not give me anything, as I also push to push to different places like repo.or.cz, sourceforge and github anyway.

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).