A working copy remembers the address of the shared repository and checks its own history against it.
The shared repository everyone pushes commits to is a bare repository: /srv/git/lab-site.git has no working files, only history (ls shows HEAD, objects, refs). A working copy on a server is made with git clone /srv/git/lab-site.git <directory>: git copies the history and remembers the repository's address under the name origin — git remote -v shows it.
git pull takes two steps. First git fetch downloads new commits into the origin/main branch — that is how the working copy sees what the repository holds now. The working files do not change at this point. Then pull brings those commits into your main branch and into the files. In the experience the refusal came at the second step: the commit was already downloaded, which is why status says “behind 'origin/main' by 1 commit”. More on fetch, pull and push — in the Wiki.
The repository has a new commit that changes lab-site.conf. You run sudo git fetch. What happens to lab-site.conf in the working copy?
-
Markers appear during a merge when both sides changed the same lines. fetch merges nothing and does not touch files.
-
The “would be overwritten” refusal happens when bringing commits into the files. fetch does not touch files, so the edit does not get in its way.
-
Files are changed by pull's second step — bringing commits into the branch. fetch only downloads them into
origin/main:git log HEAD..origin/mainshows what arrived.
git fetch only downloads commits and updates origin/main. The working files and the main branch stay the same until pull brings the commits in.
Key points
-
A bare repository keeps the shared history with no working files; the working copy knows it as
origin. -
git pullisgit fetch(download commits intoorigin/main) plus bringing them into your branch and files. -
git log HEAD..origin/mainshows commits that are downloaded but not applied yet.