Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Local Git remotes

cblgh.org

Post reply on HN
Print view View original

81–85 of 85 posts

Re: Local Git remotes

#81

Post by shmerl »

js2 wrote: post #65
shmerl wrote: post #63

Can it work with file://?

Yes: $ git init foo Initialized empty Git repository in .../foo/.git/ $ git clone "file://$PWD/foo" bar Cloning into 'bar'... But it's redundant: $ git clone bar baz Cloning into 'baz'... If you example .git/config in either clone, you'll see that remote.origin.url is the absolute path of the source repo. Note that you can share objects across clones on the same machine in various ways. See "--local", "--shared", and…

Good to know, thanks. I should try it with vim.pack for local repos.

Re: Local Git remotes

#82

Post by cerved »

fphilipe wrote: post #10
cerved wrote: post #7

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

Doesn't work. You need to mount both the worktree and the repo which defeats the point

Re: Local Git remotes

#83

Post by cerved »

yjftsjthsd-h wrote: post #71
nasretdinov wrote: post #12

You can also have multiple independent git repos that don't duplicate the full object store, via git clone --reference. It's less relevant in the container era, but otherwise it can save a lot of time and disk space when cloning repos repeatedly

Interesting; how's it compare to work trees?

Worktrees effectively share the entire state of the repo. Only limitation is that a branch can only be checked out in one repo at a time.

Clones only share the immutable object store

For most practical uses of same repo checking out different branches locally, worktrees are better.

The nice thing about clones is that you can have a backup clone, a wip clone, a review clone where you don't clutter the amount of local branch refs

Re: Local Git remotes

#84

Post by cerved »

cerved wrote: post #83
yjftsjthsd-h wrote: post #71

Earlier quoted context omitted.

Interesting; how's it compare to work trees?

Worktrees effectively share the entire state of the repo. Only limitation is that a branch can only be checked out in one repo at a time. Clones only share the immutable object store For most practical uses of same repo checking out different branches locally, worktrees are better. The nice thing about clones is that you can have a backup clone, a wip clone, a review clone where you don't clutter the amount of local…

ofc if you're running AI agents in YOLO mode — clones means you don't need to worry that Sonnet is going to see your .git/index.lock file and go "this is blocking me, let's rm -f this" and corrupt all your work that you never bothered pushing

Re: Local Git remotes

#85

Post by tracker1 »

moebrowne wrote: post #77
tracker1 wrote: post #76

Earlier quoted context omitted.

Define local... Is the same room you are in local?

The "local" were talking about is a path on the same machine. The article uses the remote `/home/user/bares/cani.git`

And local could be a separate drive, which would survive the main drive failing.
Post reply on HN