[flagged]
Local Git remotes
21–30 of 85 posts
Re: Local Git remotes
#22What'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/`.
"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.
Re: Local Git remotes
#23What'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 work with multiple agents in multiple sandboxes - they push to the local remote instead of GitHub which is now unreliable.
And I push to GitHub/GitLab from a repo outside the sandboxes.
Re: Local Git remotes
#24GitHub 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.
> thought GitHub invented git
Putting the generic term into your corporation's name can be effective means of claiming things that don't belong to you.
Jon Postel reserved 44.0.0.0/8 for a generic purpose: "amateur radio digital communications." Decades later, there was a successful heist when some enterprising individuals who had incorporated "Amateur Radio Digital Communications" misrepresented to ARIN that the assignment had actually been theirs. Immediately after ARIN gave them transfer rights, they pocketed 8 figures reselling the space to Amazon.
Github obviously isn't making explicit claims like this but they benefit whenever people with purchasing power implicitly understand that github is the only option.
edited: Amateur Radio Digital Communications is not an LLC
Re: Local Git remotes
#25A "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.
What if you have a few local machines you’re using for development, and want to keep them in sync? This method allows that single central repo without having to bounce all the code through a cloud hosting service.
OK, different meanings of word "local". TFA uses "local" to mean the same machine, not the same local network.
Re: Local Git remotes
#26GitHub 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.
One of my younger colleagues indeed displayed a mistaken impression of that kind last week.
Re: Local Git remotes
#27I was expecting the use of non-SSH git remotes without network access. Any mounted file system can be a valid remote such as a USB drive. I use file-based remote to keep some repos encrypted on S3 using Rclone.
For example, `git remote -v` would show: `secure-s3 /mnt/fuse/rclone/secure-s3/git/$REPO.git`
I think concurrency is a problem with file-based remotes but for one person keeping a desktop and laptop in sync it is much simpler than running a VPS.
Re: Local Git remotes
#28Earlier quoted context omitted.
Everything old is new again. I wouldn't be surprised if there were people that thought GitHub invented git.
> thought GitHub invented git Putting the generic term into your corporation's name can be effective means of claiming things that don't belong to you. Jon Postel reserved 44.0.0.0/8 for a generic purpose: "amateur radio digital communications." Decades later, there was a successful heist when some enterprising individuals who had incorporated "Amateur Radio Digital Communications" misrepresented to ARIN that the ass…
Do you have a source for your claims about the ARDC?
Re: Local Git remotes
#29What'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 reckon most folks have made a git oopsie and needed to re-clone a repo at least once in their career.
Having a “local remote” would be an awfully quick way to do that, especially in situations with no/low network connection or a flakey upstream server.
Re: Local Git remotes
#30What'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 reckon most folks have made a git oopsie and needed to re-clone a repo at least once in their career. Having a “local remote” would be an awfully quick way to do that, especially in situations with no/low network connection or a flakey upstream server.
> I reckon most folks have made a git oopsie and needed to re-clone a repo at least once in their career.
And I recon this is the default workflow for most people most of the time.