31–40 of 85 posts
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?
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.
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?
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'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 have lots of projects under for version control with no remotes.
I 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…
I 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…
I use Keybase's encrypted git repo the same way (to sync "private" dotfiles across laptops / remote workstations)
btw, Git also supports the HTTP protocol ...
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
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.
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?
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.