10 ms·

Using Git Offline

187 points by l_nk 3y ago

zelphirkalt 3y ago
I'm doing this for private notes, that I don't want on a git hoster. Of course without network delay, everything is super snappy. Only need to make sure, that you have backups, in case one of your disks goes up in flames or so.
wdfx 3y ago
And don't forget that each git clone can have multiple remotes. So your working copy can be simultaneously linked to any or all of GitHub, usb, local network, nas, etc.
- cbm-vic-20 3y ago
  Most users believe the 'd' in "git" (or "github") stands for "distributed".
  - wdfx 3y ago
    The real problem is that even though being distributed is cool and can help to ensure that your work exists in more than one place either for reasons of collaboration or backup, humans still like to cling to the idea of having a "single source of truth". So, if Alice collaborates by pull/pushing with Bob, and Bob works by patches over email with Charlie, and David exchanges with Charlie and Alice - then what is the "true" state of the repository exactly? The easy way out is that everyone pulls/pushes with github and we use that as "truth".
    - Double_a_92 3y ago
      Yeah either there is a central "source of truth" or all distributed copies have to always be kept in sync somehow. I don't understand all those people that romanticize "distributed" things but then just stop thinking about the practical implications of that...
      - wdfx 3y ago
        > or all distributed copies have to always be kept in sync somehow This isn't actually true. The collaborators simply have to ... collaborate. It depends on what the goal is with the data being kept in git. Git doesn't tell you how to collaborate. It could be that the group elects one person (e.g. Alice) to do releases, so, it stands that only that code which reaches Alice will ever get released. If that doesn't happen, you haven't collaborated correctly. It could be that any one of the group could release, in that case you collaborate to get your commits to any of those people. It could be that there are no releases ever made, and the group loosely exchanges their branches to build whatever interests them.
      - deleted 3y ago
        [deleted]
  - baz00 3y ago
    Most of the people I work with can barely tell the difference between git and github.
  - e12e 3y ago
    Looks like the "d" in "git" was upside down from the start...
- globular-toast 3y ago
  How do people even use GitHub without knowing this? You have to add your fork as a separate remote.
  - wdfx 3y ago
    Can you not also push back to your fork and GH guides you to make a PR from your fork/branch to the upstream? IIRC, you don't have to deal with the upstream locally?
    - kevincox 3y ago
      Yes. You only need to add the upstream repo if you want to fetch the newest changes. So it is something that you will probably only run into on your second PR. I wouldn't be surprised if the vast majority of GitHub users never send a second PR to a third-party projects. Probably the majority of users only contribute to their own (or their company's own) repos. Then a small number send at least one pull request to another user's repo. Fewer still would send more than one in a way that requires pulling new changes from upstream.
dangus 3y ago
It never occurred to me that the remote location could be a file path!
- dailykoder 3y ago
  I just learned that last year, too, when my last employer did not have any versioning tool whatsoever, except windows network shares (yes, there are more than enough companies that do it that way. It's the second time i encountered such a horror scenario). So I just set up a bare git repository on the network share and used this to keep my project there. Glad they understood that git does make sense and setup a gitlab server soon after. After all it seems kinda obvious, but hey.
- lordgrenville 3y ago
  I learned that from a different article posted here last week :) https://jeremymikkola.com/posts/2017_07_15_move_commits_between_git_repos.html#extracting-a-subdirectory-to-its-own-repo https://jeremymikkola.com/posts/2017_07_15_move_commits_betw...
- FactualActuals 3y ago
  I had to set up an entire government team's workflow that was required to be isolated completely from any network. I had to create multiple remotes that were filepaths that pointed to specific USB drives. Depending on which USB drive was connected to their laptop, a developer was able to push and pull any changes to their codebase. It felt unintuitive at the time but thinking back, this team was able to produce code much faster than other teams that didn't have a similar workflow set up.
- OskarS 3y ago
  Another cool thing that I believe git does in these situations is that it hard-links the blobs in the .git folder if you do a local clone. It makes sense: the blobs are immutable and content-addressed, no need to store two copies! Just have two links to the same file system object, save a bunch of disk space.
fjfaase 3y ago
It is also possible to exchange difference between different location using patch file with the git commands 'format-patch' and 'apply'. Patch file are usually a bit smaller and can also be easily mailed.
- vifon 3y ago
  A minor correction: it's usually preferable to apply commits with `git am` instead of `git apply`, as it applies the commit with all its metadata, not just the diff.
- palata 3y ago
  > Patch file are usually a bit smaller and can also be easily mailed. The best way to email patches is to use `git send-email`. So that the receiver can directly apply it. It's easy to get it wrong when done manually.
shoover 3y ago
Local clones and bundles are cool. I used to use hg bundle for one-off transport workflows back in the day. An offline cheat sheet of those git commands comes in hand occasionally, too.
dusted 3y ago
I often use local bare repos for experiementation, and for backup to other machines on my lan, in case my main hard drive goes dead or github decides to unexist.
classified 3y ago
I never knew I can use a folder path as a remote in git. Very handy.
heresie-dabord 3y ago
git is foundational tooling, i.e. one of the tools that a developer must know. But git is useful beyond the development community. A huge impact for a "weekend project". "The development of Git began on 3 April 2005. Torvalds announced the project on 6 April and became self-hosting the next day. The first merge of multiple branches took place on 18 April. Torvalds achieved his performance goals; on 29 April, the nascent Git was benchmarked recording patches to the Linux kernel tree at a rate of 6.7 patches per second. On 16 June, Git managed the kernel 2.6.12 release." [1] [1] _ https://en.wikipedia.org/wiki/Git#History https://en.wikipedia.org/wiki/Git#History
- ubnt00 3y ago
  I agree, it's very beneficial for non-devs. I use it to backup important configs.
  - tranceylc 3y ago
    I even use git for my resume. Makes changing the wording or rearranging things for a specific company to be slightly easier on me
  - JamesLeonis 3y ago
    I back up my Minecraft server with GIT, and use tags to track when I updated the version.
  - themadturk 3y ago
    I use it for my novel manuscripts.
- never_inline 3y ago
  Git is foundational because it's a bunch of tools dealing with a very general data structure (the DAG of file versions, or whatever the semantically correct thing to say is). Docker is something similarly powerful. It wraps around a few things (bunch of kernel namespaces, kinda reproducible, layered image format) and it is useful in many use-cases beyond microservices. There are few other tools which I can say the same about. `jq` and curl are powerful and ubiquitous. But jq is a language, and curl is a tool for interacting with so many protocols. I don't know if I can put them in the same ballpark as git and docker.
palata 3y ago
It's amazing how git is a distributed system, but everybody chooses to use it in a centralized manner with PRs (mostly on GitHub). BTW GitHub is having issues today.
- japanman185 3y ago
  [dead]
- chaxor 3y ago
  It would be wonderful if it were distributed by default more easily. For instance, an ipfs or torrent backend which automatically provides a backbone of thousands of computers with the repo on them as the remote, rather than just the single github server. Ipfs remote for git should be the default.
  - wepple 3y ago
    How reliable is IPFS for things like this? If I wanted to use git on ipfs, I could host a node and push all my git commits there, but I’d have to convince others to host it as well, correct? So perhaps it would be awesome for majorly popular projects, but still a end up having a SPOF for smaller projects right?
    - chaxor 3y ago
      The idea is to have the daemon automatically start and serve the git repo anytime a git clone is done, that way the number of nodes hosting the repo (speed of download) grows with the popularity of the repo. That way you could saturate a 10G connection on a popular repo, whereas with github you'll likely be pretty throttled or limited.
  - palata 3y ago
    It was designed around the email workflow, which is distributed by default: you send your patches to a mailing list, which is distributed between all the email servers and clients. And it's easy to host mirrors, too. GitHub and the PR workflow tend to make it all centralized.
chriswarbo 3y ago
Cool, I didn't know about 'git bundle'; nice to have another tool in my arsenal :) I like to keep a bare copy of each repo locally, and use those as remotes for my "working copies". The `git worktree` command can be used in a similar way, but I feel safer using separate clones. The article focuses on removable media (USB drives, CDs, etc.) which make automation awkward. If your remotes are more reliable (e.g. on the same machine, a LAN, or indeed the Internet) then git hooks can be useful, e.g. to propagate changes. For example, my local bare repos used hooks to (a) push to remotes on chriswarbo.net, (b) push to backups on github, (c) generate static HTML of the latest HEAD, and copy that to chriswarbo.net and IPFS. Since the article mentions bundles, a related feature is git's built-in mail support. This can be used to convert commits into a message, and apply a message as a patch. I've used this a lot to e.g. moves files from one project to another (say, helper functions from an application to a library) in a way which preserves their history (thanks to https://stackoverflow.com/a/11426261/884682 https://stackoverflow.com/a/11426261/884682 )
- TacticalCoder 3y ago
  And converting a Git repository to a bare Git repository is super easy (and can be done at any time). I keep my bare Git repositories on another machine on my LAN and push/pull/fetch/whatever using SSH (typically from Emacs, using Magit).
- eichin 3y ago
  I'm a little surprised that they talk that much about removable media without ever mentioning Git Annex...
  - kristjansson 3y ago
    Does git-annex bring anything if you're directly committing everything to git?
- 0cf8612b2e1e 3y ago
  I do not follow what you do with the bare repos. Is it just a local backup? A staging repo for tricky operations?
cookiengineer 3y ago
What's amazing is that you can also use git locally, without a server, using "git daemon". I've created a small little bash function for that, and then I just pull from machine to machine (or IP to IP) directly without needing to bother with the internet. Git is very useful this way on hackathons or when there's not much internet bandwidth to begin with. git-serve() { git daemon --reuseaddr --verbose --base-path=$PWD --export-all --enable=receive-pack -- $PWD/.git; }
- nofunsir 3y ago
  You don’t need a daemon. You can push and pull to any url, including file urls as long as you have access to the url(e.g. local file permission or network authentication with a samba server, or a shared folder on another pc), you can use it as a remote
  - ramses0 3y ago
    Including ssh, of course. `git clone $USER@example.com:/tmp/blah.git`, and `git init --bare` (for a non-checked-out, non-working-dir, "just the .git folder" file location).
    - lloeki 3y ago
      Back when GitHub was in infancy, git-web was the top crop UI, our tracker was either one of Trac or Redmine, CI was a Hudson/Jenkins hellscape, the world "cloud" referred to water in the sky, reliable VMs were a distant dream, and servers were not cheap, our team of three~four people set up decentralised git over ssh. Each developer workstation had a git user with ssh enabled and restricted to some git invocation I can't recall, and chgrp git / chmod g+rwS a conventional path, and remotes named from team members. PRs were literally that: either emails or one shouting to another over our desk that someone could git pull from one's machine straight from their (non-bare) repo. The whole development process was entirely decentralised, any one's machine was as worthy as the next one and there was no single point of failure.
      - 3y ago
bazil376 3y ago
I had to use git bundle at a government contract job where they took over a month to issue my hardware that was able to access their GitHub repo. Pretty convenient actually (compared to whatever the alternatives may be)
avgcorrection 3y ago
There’s also the “patch workflow” for when you have access to the upstream repo but you (perhaps) don’t have your own clone on the Internet. https://linux.die.net/man/7/gitworkflows https://linux.die.net/man/7/gitworkflows
- palata 3y ago
  I call this the "email workflow", as usually the natural way to share the patches is over email :-)
globular-toast 3y ago
Far too many people think of git as a tool to push/pull code from a remote location. A glorified scp basically. Git is a distributed version control system.
minroot 3y ago
Is this viable as a file synchronization system?
- dogleash 3y ago
  depends on your use case and requirements it's a source control tool, the whole purpose is file synchronization tailored to a specific use case
- urda 3y ago
  git is not a great choice for large files, which is why git-lfs is a thing too.
- aragilar 3y ago
  https://git-annex.branchable.com/ https://git-annex.branchable.com/ is the tool you want.
tonymet 3y ago
git is great for non-centralized workflows. Sometimes your local copy lacks internet or authentication credentials ... * git-ssh to "deploy" to a remote repo that is not on the internet or lacks authentication keys * git remote with files (local) to push changes to a deployment outside of the development directory -- e.g. to /etc , /bin or another build location * bare git repo for config, e.g. /etc or for dotfiles (~/) . Then git fetch to your proper repo for recording history.
- crtasm 3y ago
  Is git-ssh a typo? I can't find what you mean.
jpc0 3y ago
Seeing as it's come up a ton in this comment section... https://git-scm.com/docs/gitworkflows https://git-scm.com/docs/gitworkflows Also there... https://git-scm.com/docs/giteveryday https://git-scm.com/docs/giteveryday
velcrovan 3y ago
Fossil (https://www.fossil-scm.org https://www.fossil-scm.org) is superior for this use case in almost every way I can think of. It was in many ways designed for this use case. A fossil repository is a single-file SQLite database. You can copy that single file to another computer and treat it like a remote, sync with it, etc. with a simple "fossil sync" command. The single file includes all the ticketing (issues), wiki, discussion forum and all branches, and those are all synced as well. There's no need to do any special packaging or bundling. Plus you get a built in web UI.
- deleted 3y ago
  [deleted]
nayuki 3y ago
Great article. Also note that git-bundle can be used to manually transfer a range of commits between two computers. Suppose the sender's repository is at version 10 but the receiver is at version 4. On the sender's side, you can request to create a bundle of versions 5 through 10 and save that as a single file. You can move the file to the receive using whatever method you choose. On the receiver side, you can essentially "git pull" that set of patches. This technique has helped me in quite a few environments.
m463 3y ago
I love the website. clear and readable, just one stylesheet, no javascript.

187 points by l_nk 3y ago

I'm doing this for private notes, that I don't want on a git hoster. Of course without network delay, everything is super snappy. Only need to make sure, that you have backups, in case one of your disks goes up in flames or so.

wdfx 3y ago

And don't forget that each git clone can have multiple remotes. So your working copy can be simultaneously linked to any or all of GitHub, usb, local network, nas, etc.

cbm-vic-20 3y ago
Most users believe the 'd' in "git" (or "github") stands for "distributed".
- wdfx 3y ago
  The real problem is that even though being distributed is cool and can help to ensure that your work exists in more than one place either for reasons of collaboration or backup, humans still like to cling to the idea of having a "single source of truth". So, if Alice collaborates by pull/pushing with Bob, and Bob works by patches over email with Charlie, and David exchanges with Charlie and Alice - then what is the "true" state of the repository exactly? The easy way out is that everyone pulls/pushes with github and we use that as "truth".
  - Double_a_92 3y ago
    Yeah either there is a central "source of truth" or all distributed copies have to always be kept in sync somehow. I don't understand all those people that romanticize "distributed" things but then just stop thinking about the practical implications of that...
    - wdfx 3y ago
      > or all distributed copies have to always be kept in sync somehow This isn't actually true. The collaborators simply have to ... collaborate. It depends on what the goal is with the data being kept in git. Git doesn't tell you how to collaborate. It could be that the group elects one person (e.g. Alice) to do releases, so, it stands that only that code which reaches Alice will ever get released. If that doesn't happen, you haven't collaborated correctly. It could be that any one of the group could release, in that case you collaborate to get your commits to any of those people. It could be that there are no releases ever made, and the group loosely exchanges their branches to build whatever interests them.
    - deleted 3y ago
      [deleted]
- baz00 3y ago
  Most of the people I work with can barely tell the difference between git and github.
- e12e 3y ago
  Looks like the "d" in "git" was upside down from the start...
globular-toast 3y ago
How do people even use GitHub without knowing this? You have to add your fork as a separate remote.
- wdfx 3y ago
  Can you not also push back to your fork and GH guides you to make a PR from your fork/branch to the upstream? IIRC, you don't have to deal with the upstream locally?
  - kevincox 3y ago
    Yes. You only need to add the upstream repo if you want to fetch the newest changes. So it is something that you will probably only run into on your second PR. I wouldn't be surprised if the vast majority of GitHub users never send a second PR to a third-party projects. Probably the majority of users only contribute to their own (or their company's own) repos. Then a small number send at least one pull request to another user's repo. Fewer still would send more than one in a way that requires pulling new changes from upstream.

dangus 3y ago

It never occurred to me that the remote location could be a file path!

dailykoder 3y ago
I just learned that last year, too, when my last employer did not have any versioning tool whatsoever, except windows network shares (yes, there are more than enough companies that do it that way. It's the second time i encountered such a horror scenario). So I just set up a bare git repository on the network share and used this to keep my project there. Glad they understood that git does make sense and setup a gitlab server soon after. After all it seems kinda obvious, but hey.
lordgrenville 3y ago
I learned that from a different article posted here last week :) https://jeremymikkola.com/posts/2017_07_15_move_commits_between_git_repos.html#extracting-a-subdirectory-to-its-own-repo https://jeremymikkola.com/posts/2017_07_15_move_commits_betw...
FactualActuals 3y ago
I had to set up an entire government team's workflow that was required to be isolated completely from any network. I had to create multiple remotes that were filepaths that pointed to specific USB drives. Depending on which USB drive was connected to their laptop, a developer was able to push and pull any changes to their codebase. It felt unintuitive at the time but thinking back, this team was able to produce code much faster than other teams that didn't have a similar workflow set up.
OskarS 3y ago
Another cool thing that I believe git does in these situations is that it hard-links the blobs in the .git folder if you do a local clone. It makes sense: the blobs are immutable and content-addressed, no need to store two copies! Just have two links to the same file system object, save a bunch of disk space.

fjfaase 3y ago

It is also possible to exchange difference between different location using patch file with the git commands 'format-patch' and 'apply'. Patch file are usually a bit smaller and can also be easily mailed.

vifon 3y ago
A minor correction: it's usually preferable to apply commits with `git am` instead of `git apply`, as it applies the commit with all its metadata, not just the diff.
palata 3y ago
> Patch file are usually a bit smaller and can also be easily mailed. The best way to email patches is to use `git send-email`. So that the receiver can directly apply it. It's easy to get it wrong when done manually.

shoover 3y ago

Local clones and bundles are cool. I used to use hg bundle for one-off transport workflows back in the day. An offline cheat sheet of those git commands comes in hand occasionally, too.

dusted 3y ago

I often use local bare repos for experiementation, and for backup to other machines on my lan, in case my main hard drive goes dead or github decides to unexist.

classified 3y ago

I never knew I can use a folder path as a remote in git. Very handy.

heresie-dabord 3y ago

git is foundational tooling, i.e. one of the tools that a developer must know. But git is useful beyond the development community. A huge impact for a "weekend project". "The development of Git began on 3 April 2005. Torvalds announced the project on 6 April and became self-hosting the next day. The first merge of multiple branches took place on 18 April. Torvalds achieved his performance goals; on 29 April, the nascent Git was benchmarked recording patches to the Linux kernel tree at a rate of 6.7 patches per second. On 16 June, Git managed the kernel 2.6.12 release." [1] [1] _ https://en.wikipedia.org/wiki/Git#History https://en.wikipedia.org/wiki/Git#History

ubnt00 3y ago
I agree, it's very beneficial for non-devs. I use it to backup important configs.
- tranceylc 3y ago
  I even use git for my resume. Makes changing the wording or rearranging things for a specific company to be slightly easier on me
- JamesLeonis 3y ago
  I back up my Minecraft server with GIT, and use tags to track when I updated the version.
- themadturk 3y ago
  I use it for my novel manuscripts.
never_inline 3y ago
Git is foundational because it's a bunch of tools dealing with a very general data structure (the DAG of file versions, or whatever the semantically correct thing to say is). Docker is something similarly powerful. It wraps around a few things (bunch of kernel namespaces, kinda reproducible, layered image format) and it is useful in many use-cases beyond microservices. There are few other tools which I can say the same about. `jq` and curl are powerful and ubiquitous. But jq is a language, and curl is a tool for interacting with so many protocols. I don't know if I can put them in the same ballpark as git and docker.

palata 3y ago

It's amazing how git is a distributed system, but everybody chooses to use it in a centralized manner with PRs (mostly on GitHub). BTW GitHub is having issues today.

japanman185 3y ago
[dead]
chaxor 3y ago
It would be wonderful if it were distributed by default more easily. For instance, an ipfs or torrent backend which automatically provides a backbone of thousands of computers with the repo on them as the remote, rather than just the single github server. Ipfs remote for git should be the default.
- wepple 3y ago
  How reliable is IPFS for things like this? If I wanted to use git on ipfs, I could host a node and push all my git commits there, but I’d have to convince others to host it as well, correct? So perhaps it would be awesome for majorly popular projects, but still a end up having a SPOF for smaller projects right?
  - chaxor 3y ago
    The idea is to have the daemon automatically start and serve the git repo anytime a git clone is done, that way the number of nodes hosting the repo (speed of download) grows with the popularity of the repo. That way you could saturate a 10G connection on a popular repo, whereas with github you'll likely be pretty throttled or limited.
- palata 3y ago
  It was designed around the email workflow, which is distributed by default: you send your patches to a mailing list, which is distributed between all the email servers and clients. And it's easy to host mirrors, too. GitHub and the PR workflow tend to make it all centralized.

chriswarbo 3y ago

Cool, I didn't know about 'git bundle'; nice to have another tool in my arsenal :) I like to keep a bare copy of each repo locally, and use those as remotes for my "working copies". The `git worktree` command can be used in a similar way, but I feel safer using separate clones. The article focuses on removable media (USB drives, CDs, etc.) which make automation awkward. If your remotes are more reliable (e.g. on the same machine, a LAN, or indeed the Internet) then git hooks can be useful, e.g. to propagate changes. For example, my local bare repos used hooks to (a) push to remotes on chriswarbo.net, (b) push to backups on github, (c) generate static HTML of the latest HEAD, and copy that to chriswarbo.net and IPFS. Since the article mentions bundles, a related feature is git's built-in mail support. This can be used to convert commits into a message, and apply a message as a patch. I've used this a lot to e.g. moves files from one project to another (say, helper functions from an application to a library) in a way which preserves their history (thanks to https://stackoverflow.com/a/11426261/884682 https://stackoverflow.com/a/11426261/884682 )

TacticalCoder 3y ago
And converting a Git repository to a bare Git repository is super easy (and can be done at any time). I keep my bare Git repositories on another machine on my LAN and push/pull/fetch/whatever using SSH (typically from Emacs, using Magit).
eichin 3y ago
I'm a little surprised that they talk that much about removable media without ever mentioning Git Annex...
- kristjansson 3y ago
  Does git-annex bring anything if you're directly committing everything to git?
0cf8612b2e1e 3y ago
I do not follow what you do with the bare repos. Is it just a local backup? A staging repo for tricky operations?

cookiengineer 3y ago

What's amazing is that you can also use git locally, without a server, using "git daemon". I've created a small little bash function for that, and then I just pull from machine to machine (or IP to IP) directly without needing to bother with the internet. Git is very useful this way on hackathons or when there's not much internet bandwidth to begin with. git-serve() { git daemon --reuseaddr --verbose --base-path=$PWD --export-all --enable=receive-pack -- $PWD/.git; }

nofunsir 3y ago
You don’t need a daemon. You can push and pull to any url, including file urls as long as you have access to the url(e.g. local file permission or network authentication with a samba server, or a shared folder on another pc), you can use it as a remote
- ramses0 3y ago
  Including ssh, of course. `git clone $USER@example.com:/tmp/blah.git`, and `git init --bare` (for a non-checked-out, non-working-dir, "just the .git folder" file location).
  - lloeki 3y ago
    Back when GitHub was in infancy, git-web was the top crop UI, our tracker was either one of Trac or Redmine, CI was a Hudson/Jenkins hellscape, the world "cloud" referred to water in the sky, reliable VMs were a distant dream, and servers were not cheap, our team of three~four people set up decentralised git over ssh. Each developer workstation had a git user with ssh enabled and restricted to some git invocation I can't recall, and chgrp git / chmod g+rwS a conventional path, and remotes named from team members. PRs were literally that: either emails or one shouting to another over our desk that someone could git pull from one's machine straight from their (non-bare) repo. The whole development process was entirely decentralised, any one's machine was as worthy as the next one and there was no single point of failure.
    - 3y ago

bazil376 3y ago

I had to use git bundle at a government contract job where they took over a month to issue my hardware that was able to access their GitHub repo. Pretty convenient actually (compared to whatever the alternatives may be)

avgcorrection 3y ago

There’s also the “patch workflow” for when you have access to the upstream repo but you (perhaps) don’t have your own clone on the Internet. https://linux.die.net/man/7/gitworkflows https://linux.die.net/man/7/gitworkflows

palata 3y ago
I call this the "email workflow", as usually the natural way to share the patches is over email :-)

globular-toast 3y ago

Far too many people think of git as a tool to push/pull code from a remote location. A glorified scp basically. Git is a distributed version control system.

minroot 3y ago

Is this viable as a file synchronization system?

dogleash 3y ago
depends on your use case and requirements it's a source control tool, the whole purpose is file synchronization tailored to a specific use case
urda 3y ago
git is not a great choice for large files, which is why git-lfs is a thing too.
aragilar 3y ago
https://git-annex.branchable.com/ https://git-annex.branchable.com/ is the tool you want.

tonymet 3y ago

git is great for non-centralized workflows. Sometimes your local copy lacks internet or authentication credentials ... * git-ssh to "deploy" to a remote repo that is not on the internet or lacks authentication keys * git remote with files (local) to push changes to a deployment outside of the development directory -- e.g. to /etc , /bin or another build location * bare git repo for config, e.g. /etc or for dotfiles (~/) . Then git fetch to your proper repo for recording history.

crtasm 3y ago
Is git-ssh a typo? I can't find what you mean.

jpc0 3y ago

Seeing as it's come up a ton in this comment section... https://git-scm.com/docs/gitworkflows https://git-scm.com/docs/gitworkflows Also there... https://git-scm.com/docs/giteveryday https://git-scm.com/docs/giteveryday

velcrovan 3y ago

Fossil (https://www.fossil-scm.org https://www.fossil-scm.org) is superior for this use case in almost every way I can think of. It was in many ways designed for this use case. A fossil repository is a single-file SQLite database. You can copy that single file to another computer and treat it like a remote, sync with it, etc. with a simple "fossil sync" command. The single file includes all the ticketing (issues), wiki, discussion forum and all branches, and those are all synced as well. There's no need to do any special packaging or bundling. Plus you get a built in web UI.

deleted 3y ago
[deleted]

nayuki 3y ago

Great article. Also note that git-bundle can be used to manually transfer a range of commits between two computers. Suppose the sender's repository is at version 10 but the receiver is at version 4. On the sender's side, you can request to create a bundle of versions 5 through 10 and save that as a single file. You can move the file to the receive using whatever method you choose. On the receiver side, you can essentially "git pull" that set of patches. This technique has helped me in quite a few environments.

m463 3y ago

I love the website. clear and readable, just one stylesheet, no javascript.