On Tue, Apr 17, 2018 at 8:34 AM, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote: > On Tue, 17 Apr 2018, Junio C Hamano wrote: > >> Jacob Keller <jacob.keller@xxxxxxxxx> 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. > > ... snip ... > > oh, i totally buy all that now, i'm just suggesting that the man > page might be tweaked to make that more obvious. in "man git-remote", > under "set-url", remember that it reads: > > "Note that the push URL and the fetch URL, even though they can be set > differently, must still refer to the same place." > > i think it would be useful to be more specific about what "can be > set differently" means, since a lot of readers might not immediately > appreciate that it means just, say, the transport protocols. it never > hurts to add that little bit of detail. > > rday > > Maybe something like: "Note that the push URL and the fetch URL, even though they can be set differently, are expected to refer to the same repository. For example, the fetch URL might use an unauthenticated transport, while the push URL generally requires authentication" Then follow this bit with the mention of multiple remotes. (I think "repository" conveys the meaning better than "place". Technically, the URLs can be completely different as long as they end up contacting the same real server repository.) Thanks, Jake
