Shourya Shukla <shouryashukla.oo@xxxxxxxxx> writes: > I thought it would be OK to describe a maybe *unorthodox* way to do > this. I will remove it in the next version. The thing is that it is not just unorthodox but it is wrong and broken. Imagine that your 'origin' fetches from upstream that is controlled by me (e.g. at https://github.com/git/git/) and pushes to your publishing repository controled by you. After you fetch from me after my 'master' branch advances, of course, remote/origin/master would be updated in your repository. When you work on your own changes on your 'master' (perhaps you do "pull --rebase origin") and push the result to your publishing repository, which you also call 'origin' because you configured the remotes in your "unorthodox" way, the remote-tracking branch remotes/origin/master would also be updated from your 'master' (i.e. we pretend that we fetched the remote-tracking branches from the same remote immediately after we pushed out). But if you actually fetch from 'origin', I wouldn't have your changes on my 'master' yet, and you won't be seeing your commits in your remotes/origin/master. I.e. the "unorthodox" way breaks your remote-tracking branch, and not recommendable for any usecase. Having said all that, because this is a single-topic FAQ entry that covers only the "remote", we should clarify the existing description in Documentation/git-remote.txt and also possibly config variables the subsystem uses so that anything readers would learn by understanding these three bullet points we just discussed are covered there. And then have a small paragraph that has only the question and "see that section on that manual page" reference, and no duplicated explanation, in the FAQ file.
