Re: man page for "git remote set-url" seems confusing/contradictory
- From
Jacob Keller <jacob.keller@gmail.com>
- Date
- Apr 17, 2018, 01:01 UTC
- Message-ID
- <CA+P7+xrY83CM6WYoxio2nPGzeg1YNGbptM52Opu2UBgdk9Y-4A@mail.gmail.com>
- In-Reply-To
- <xmqqefjewxr4.fsf@gitster-ct.c.googlers.com>
On Mon, Apr 16, 2018 at 4:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 25 quoted lines
> Jacob Keller <jacob.keller@gmail.com> writes: > >> Things won't work so well if you set the push url and fetch url to >> different repositories. Git assumes that refs updated by "push" will >> also be reflected via "fetch". >> >> I don't know offhand what will break, but likely something will. For >> one, when you fetch again it will rewind your remotes after the push. > > Exactly. I still haven't fully embraced it myself, but for a long > time, "git push" pretends as if it fetched from that remote and > updates the corresponding remote tracking branches (if you have > any), so you'll be inviting inconsistent behaviour if you set your > fetch and push URLs pointing at two logically separate places. > > This is a tangent, but there probably should be a boolean that > disables this feature in "git push" per destination repository, > i.e. "when pushing into this repository, pretend that we immediately > fetched from the refs we just pushed to and update the remote > tracking branches we have for them: yes/no". It is not entirely > implausible to envision an overly smart remote repository that turns > a non-fast-forward push into an automatic rebase when it is safe to > do so, instead of failing such a push, and you'd disable the "assume > what we pushed would appear there" when talking to such a remote. >
Not to mention something like gerrit which uses magical references "refs/publish/branchname" which don't actually get generated on the server.
Thanks, Jake