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

71–80 of 85 posts

Re: Local Git remotes

#71

Post by yjftsjthsd-h »

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?

Re: Local Git remotes

#72

Post by fwip »

mystifyingpoi wrote: post #59
fwip wrote: post #22

Earlier quoted context omitted.

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

/shrug It's more local than github is. Whether it's a server running in your basement, or the filesystem served by the next rack over in your on-prem datacenter, it doesn't seem unreasonable to refer to it as 'local' in certain contexts, to contrast with remotes that are further away.

Re: Local Git remotes

#73

Post by dogscatstrees »

Nice. Claude likes it, especially when the AI detects PII and knows by policy to halt the commit to cloud but not local.

> A related trick worth knowing — one git push can fan out to two destinations:

git remote set-url --add --push origin ~/bares/.git # add a 2nd push URL # now `git push origin` writes to GitHub AND the local bare repo

Re: Local Git remotes

#74

Post by neuronexmachina »

elevation wrote: post #47
neuronexmachina wrote: post #28

Earlier quoted context omitted.

Do you have a source for your claims about the ARDC?

This lengthy email thread[0] indicates that Jon Postel made the assignment in 1992, that the entity "Amateur Radio Digital Communications" wasn't formed until years later, meaning Jon's assignment had to have been for a purpose and not to an entity of the same name. The head of ARIN defends[1] the transfer throughout the thread. [0]: https://seclists.org/nanog/2019/Jul/366 [1]: https://seclists.org/nanog/2019/Jul/458

From your earlier comment it sounded like there was a "heist" simply based on having a similar name. Looking into it though, it seems like the ARDC non-profit did a pretty reasonable job of proving they were the same folks who'd been managing the IP block for decades. Also, has there been any sort of allegation that they've misused the funds? From what I understand they've pretty consistently used the funds to support amateur radio.

Re: Local Git remotes

#75

Post by kmarc »

theptip wrote: post #35
kmarc wrote: post #34

Earlier quoted context omitted.

I use Keybase's encrypted git repo the same way (to sync "private" dotfiles across laptops / remote workstations)

How is Keybase doing these days? I stopped following after the acquisition, but I like the concept.

Stalled...? I even had to look up the name using "pgp social network xlm" as search terms.

App still working tho.

Re: Local Git remotes

#76

Post by tracker1 »

mystifyingpoi wrote: post #57
tracker1 wrote: post #53

Earlier quoted context omitted.

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.

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

Re: Local Git remotes

#78

Post by codepack »

In my experience, local remotes shine when you have multiple clones of the same repo on the same machine (e.g., different working trees) and you want to share objects without re-downloading or using symlinks. Also, for quick offline backups: `git push /mnt/backup/repo.git --all` is dead simple. To answer mystifyingpoi's question, one reason to push to a local remote is if you want a separate copy that isn't affected by your branch naming—or if you're using multiple clients (like a work and personal repo) that need to sync when network is available later.

Re: Local Git remotes

#79

Post by nasretdinov »

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 are different checkouts of the same repo. Clone with --reference is a separate repo altogether, with its own .git and worktree.
Post reply on HN