git: setting a remote to the local repository itself

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.

Well while you are at it, why not try add a repo to itself as a submodule? — jingx
– jingx, Commented Oct 10, 2020 at 4:59

torek · Accepted Answer · 2020-10-10 23:48:42Z

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 or 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.

setting the upstream to be another branch in the repository, interesting! i guess that wouldn't cause the repo to be twice as large, because the branch would just point to the same objects in the git database, right?
Right—in fact, with another Git repository, the same thing happens. Commits are really identified by their hash IDs. Branch names, and other names like remote-tracking names, just hold hash IDs. (Branch names get these other features, like upstreams, through the .git/config file, rather than because they are branch names.)
i see. i guess what i was trying to say was, unlike if you had a second repository (a --bare one) on your computer that was the 'remote', using two branches in the same repo does not double the disk usage.
Ah, I see. Yes, if you have two separate repositories, you get increased storage use (assuming no underlying shared storage—there are external storage systems that de-duplicate, e.g., NFS to a ZFS file server can de-duplicate even across separate hosts).
One thing I'll go so far as to call a correction: local paths are not urls at all, and aren't treated that way. You can do things with local-path clones/remotes you can't do with url clones/remotes.

Collectives™ on Stack Overflow

git: setting a remote to the local repository itself

1 Answer 1

7 Comments

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

7 Comments

Related