14

When would the Fetch URL and Push URL not be the same for a certain remote?

For example, when i run git remote show central for a remote named central, the output looks like:

* remote central
  Fetch URL: aoberoi@example.com:/home/aoberoi/Repositories/example.git
  Push  URL: aoberoi@example.com:/home/aoberoi/Repositories/example.git
  HEAD branch: master
  Remote branch:
    master tracked

I just don't see why I would be fetching from and pushing to two different URLs, what type of workflow is this intended for?

Mark Fisher
  • 965
  • 1
  • 11
  • 30
Ankur
  • 2,792
  • 3
  • 23
  • 26
  • I typically set up github fetch with https, it avoids the need to unlock my ssh key for refreshing the latest changes. And depending on the ssh layer used it’s also faster. The advantage is smaller if the repo requires authenticated users for read. – eckes Sep 15 '18 at 20:06

2 Answers2

12

I am not sure what you mean, since your example includes 2 identical URL, but URLS for push and pull can differ because of:

  • protocol issue: see Git protocols: the url will be slightly different because not every protocol supports push operations (http for instance, except in case of smart http)
  • intermediate repos: you can push to a different repository which will be the "middle man" between the true "central" repo and yours. Certains operations can then be performed (through a post-receive hook for instance), and the commit will then be pushed to the "actual" remote from there if those operations (like "unit testing", "static code analysis" ...) pass successfully.
    For instance of such a usage, see:
    "What is the cleverest use of source repository that you have ever seen?".

That being said, commit 697f652 (Git 2.3.1+, Q1/Q2 2015) by Git maintainer Junio C Hamano (gitster) do mention:

It seems to be a common mistake to try using a single remote (e.g. 'origin') to fetch from one place (i.e. upstream) while pushing to another (i.e. your publishing point).

That will never work satisfactorily, and it is easy to understand why if you think about what refs/remotes/origin/* would mean in such a world. It fundamentally cannot reflect the reality.
If it follows the state of your upstream, it cannot match what you have published, and vice versa.

The documentation wasn't clear that "remote.<nick>.pushURL" and "remote.<nick>.URL" are there to name the same repository accessed via different transports, not two separate repositories.

yaitloutou
  • 1,691
  • 19
  • 23
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

I think you could use it if you wanted a "staging" repo contributors would push to, and then others would push changes from there to the main repo after review and approval. So you'd fetch from the main repo, and push to the staging repo.

Laurence Gonsalves
  • 137,896
  • 35
  • 246
  • 299