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

11–20 of 85 posts

Re: Local Git remotes

#11

Post by cyanydeez »

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…

which harness has actual containment controls and not just suggestions?

Re: Local Git remotes

#12

Post by nasretdinov »

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

Re: Local Git remotes

#13

Post by orev »

alsobrsp wrote: post #3
antiframe wrote: post #2

GitHub has been such a staple of the modern dev that some are now (re)discovering git is distributed.

Everything old is new again. I wouldn't be surprised if there were people that thought GitHub invented git.

That assumption has come up in almost every conversation I’ve ever had with semi-technical people regarding git, so the confusion is just a fact. It happens so often, I think Linus (or whoever controlled the git trademarks at the time) should have demanded GitHub change their name when it was launched.

Re: Local Git remotes

#14

Post by pokstad »

mystifyingpoi wrote: post #5

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?

I use this to push changes to a local encrypted sparse bundle image, and then I periodically rsync that image to a remote disk. Git has no built in encrypted storage, so pushing directly to a remote means you trust that remote.

Re: Local Git remotes

#16

Post by ulrikrasmussen »

mystifyingpoi wrote: post #5

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?

I am also seriously puzzled and don't see the point. Why push to a local remote if the real remote is not reachable? The branch is still not leaving your machine, you are just making a copy of it in another place and now have to manage `local/` refs in addition to `origin/`.

Re: Local Git remotes

#17

Post by adregan »

mystifyingpoi wrote: post #5

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?

A decade ago I was working with an intern who wasn’t allowed access to push to any branch. As I wanted him to get experience with the development cycle, I set up a bare repo in a shared Dropbox folder and had him push code there.

Aside from that unique use case, I might consider this for storing code on a network attached drive (archival).

Re: Local Git remotes

#18

Post by [deleted] »

mystifyingpoi wrote: post #5

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?

[deleted]

Re: Local Git remotes

#19

Post by [deleted] »

mystifyingpoi wrote: post #5

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?

[deleted]
Post reply on HN