git：将远程设置为本地存储库本身

Question

let's create a new git repository:

$ git init test
$ cd test

and then add a remote, pointing to ourselves

$ git remote add origin .

note the dot, referring to the test directory.

this seems to function as expected. you can make commits, set up branch tracking, and push and pull from yourself. the only strange thing i've run into is that if you commit, then fetch, your unpushed changes are already present if you go to push (it makes sense why this happens, but it's perhaps unexpected).

is this functionality stable / intended? what are the consequences of using a remote like this? will any git command usages error out on a repository like this? are there any real use cases?

I was thinking this might be good for getting git functionality minus the replication (as opposed to pushing to a bare repository on your same computer)

this seems like a strange feature, and i'm surprised i haven't found any discussion on it anywhere.

Answer 1

It's not a specific feature. It just falls naturally out of the fact that a remote is a short name for a URL where we'll find some other Git repository. Normally . would not be a URL—you'd have to spell out file:///path/to/git/repo for instance—but Git accepts certain extended URLs, including anything that is a valid path name. ¹

It does turn two things on their heads, though:

• Normally origin is short for something longer . Here, origin is now "short" for . , which is shorter .

• Normally, the other Git repository is another Git repository. Here, it's your own Git repository. That's what makes some of things feel a little weird.

There's no particular reason to bother with a name for the "other" Git repository though: just use git fetch . refspec git fetch . refspec or git push . refspec git push . refspec . This leaves you without the convenience of setting an upstream for these two operations, but you can set the upstream of a (local) branch to be another (local) branch, which gets most of the convenience back.

---

¹ As jthill notes in a comment , using a path name here changes some visible behaviors: in particular Git will, at clone time, make hard links to local-file-system objects if this is possible. Using file:// URLs disables this (as does --no-local ). So while the path occupies the syntactic location for a URL, it isn't really a URL.