Live data from Hacker News

Local Git remotes

cblgh.org

51–60 of 85 posts

Re: Local Git remotes

#51

I love reading articles like this. It's kinda of a slap in the face – "hey guys, you know that thing you've been doing for decades, well for decades you've had this ability to do it with your own stuff if you just spend a few human brain tokens on it". btw, Git also supports the HTTP protocol ...

> btw, Git also supports the HTTP protocol ...

In fact, Git supports any protocol! If you add a git remote like

    git remote add my-remote my-super-duper-protocol::some-sort-of-address-thingy
Then pushing/pulling `my-remote` will try to invoke a command called `git-remote-my-super-duper-protocol`, with `some-sort-of-address-thingy` in its arguments. You can implement that however you like.

I use remotes like "pkipfs::y5a9inx61aski4miz4sgmg55qgbazxhfwab3i6ee1ypa6rnumi8o", which invokes a custom git-remote-pkipfs command that pushes/pulls object data to IPFS and resolves/updates refs as subdomains of a specified pkarr address.

Re: Local Git remotes

#52

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

Would git worktrees be useful in that use case? It just adds a new checkout in a different directory without duplicating the git data (blob storage).

Re: Local Git remotes

#53

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?

Depends on if/how you're communication and/or working with others... lets say github/devops/whatever is down... but you're still wanting to get work done and collaborating with other devs.

Being able to target a shared SSH server in your control while the upstream service is down is pretty freeing... and even if you aren't releasing to production/test/etc, you can keep making shared progress.. even more important with trunk based development.

Re: Local Git remotes

#55
post #31

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.

Yeah, I don’t get it either. The command is `git init` and you’re done.

Re: Local Git remotes

#56

A "local remote" is a contradiction. Unless the remote is on a different disk you are just wasting space. Even then the point of remotes is for sharing, not for backup/redundancy.

I use them ALL THE TIME. If anything, I have my 'local remote' in my Syncthing shared dir - its great for sharing code between my dev workstation(s) w/o using Github, etc.

Re: Local Git remotes

#57

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?

Depends on if/how you're communication and/or working with others... lets say github/devops/whatever is down... but you're still wanting to get work done and collaborating with other devs. Being able to target a shared SSH server in your control while the upstream service is down is pretty freeing... and even if you aren't releasing to production/test/etc, you can keep making shared progress.. even more important wit…

But "shared SSH server" isn't local.

Re: Local Git remotes

#58
post #31

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.

I can imagine it being useful for some obscure setup of local CI (like Jenkins) that expects a Git URL and for whatever reason cannot just copy files from one directory to another. Or maybe Argo/Flux tinkering to mimic real repo. But nothing usual should require such tricks.

Re: Local Git remotes

#59
post #22

Earlier quoted context omitted.

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/`.

"local" can also be a network fileshare. It could also be in a directory that is treated differently than your other checkouts - whether that's something like deployment, sharing over the web, running CI, etc.

"network fileshare" is not local. By the same logic, I can mount S3 bucket over fuse and call it "local". Sure, it will work, but in the context it is just nonsense.

Re: Local Git remotes

#60

Earlier quoted context omitted.

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.

I can imagine it being useful for some obscure setup of local CI (like Jenkins) that expects a Git URL and for whatever reason cannot just copy files from one directory to another. Or maybe Argo/Flux tinkering to mimic real repo. But nothing usual should require such tricks.

There is no such thing as a git url. It is just a URI parser for the endpoint, which could be local filesystem, NFS, SSH, etc. Being able to HTTP fetch is/was an afterthought.
Post reply on HN