61–70 of 85 posts
Earlier quoted context omitted.
I use local remotes all the time for testing as a form of "local CI". Check it out from '/tmp' and make sure it still builds. For a single-dev or small team, it beats having to do github runner epicycles to accomplish the same basic goal. Add in Firejail if you want environment isolation.
I do the same sometimes, but a one-off clone is not quite the same as maintaining a "local remote" and pushing refs to it.
What's the purpose of this? I don't get it. Why push at all to "local remote", if you can just keep your changes on a local branch, and push it whenever "remote remote" becomes available again?
git user is restricted to git-shell and the agent has a passwordless SSH key to access git@host:/home/git/project.git. On the host, I push/pull to git@localhost:/home/git/project.git (sidestepping fiddling with git safe.directory settings for each project).
Seemed like an easy way for local sync without giving the untrusted VM access to a writable shared filesystem?
Earlier quoted context omitted.
I've used it to quickly start a git project, with source control, no credentials to deal with, etc eventually I can set up a proper git repo, set up credentials, etc. I think it's like how some people use 127.0.0.1 for stuff, then later expand the software engineering process to do it right.
I don’t understand. A proper git repo is… your git repo. Git is distributed. I have lots of projects under for version control with no remotes.
backup? peace of mind?
Can it work with file://?
$ git init foo
Initialized empty Git repository in .../foo/.git/
$ git clone "file://$PWD/foo" bar
Cloning into 'bar'...
$ git clone bar baz
Cloning into 'baz'...
Note that you can share objects across clones on the same machine in various ways. See "--local", "--shared", and "--reference" in the git-clone man page. (GitHub uses this feature heavily. Or at least they did. I have no idea what their backend implementation is these days, but they must be doing some sort of copy-on-write CAS for forks.)
you can also setup a local remote which hardlinks the index so it doesn't occupy more space. Why? Idk. You don't want to share stash, rerere-cache, branches whatever. Also handy if you're running an agent in a container on the local fs. Set up a local clone, contain the agent to that repo folder and have it hack away on that. Later, you step out of the container and do the syncing. You can't use worktrees in this sit…
I think you mean hardlinks the object database? The index (staging area) changes constantly. Not much point in hardlinking it.
Hardlinking the object database is the default behavior with you clone locally on linux. It's great for one-off clones such as CI/CD pipelines and agentic containers, but the benefit in terms of disk space saved is short-lived: as repos evolve independently, they replace their packfiles with new ones, and the new ones will not be hardlinked because they don't contain the same objects.
I like to keep bare repositories in dropbox, but I use `--no-hardlinks` when cloning, because before I did that, on one occasion, dropbox corrupted the bare repo, and my working repo was corrupted as a result.
What's the purpose of this? I don't get it. Why push at all to "local remote", if you can just keep your changes on a local branch, and push it whenever "remote remote" becomes available again?
Within certain bounds git behaves quite nicely with a directory of bare git repos and Syncthing.
you can also setup a local remote which hardlinks the index so it doesn't occupy more space. Why? Idk. You don't want to share stash, rerere-cache, branches whatever. Also handy if you're running an agent in a container on the local fs. Set up a local clone, contain the agent to that repo folder and have it hack away on that. Later, you step out of the container and do the syncing. You can't use worktrees in this sit…
At that point you might as well use a worktree[1]. [1]: https://git-scm.com/docs/git-worktree
git push . :
git pull . :