6 ms·

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

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.
    - _ZeD_ 3y ago
      I would have used svn and a proper server. and if you start bragging about the "decentralization"... well, there is a reason anyone now uses a gitHUB, where there is a proper, centralized, version online
      - palata 3y ago
        > where there is a proper, centralized, version online Linux has a proper, centralized, version online. Still their collaboration workflow (they use the email workflow) is decentralised. I think everybody uses GitHub now because they don't know the email workflow, and it's more convenient to have one account on GitHub than having one account on every instance of GitLab you contribute to. And I guess most people only know the GitHub web interface and don't really feel like using something else. My point being that there are many reasons why everybody is using GitHub, but it does not mean that the PR workflow is better. What do you think?
        pmontra 3y ago
        All my current customers are using Bitbucket, but it's the same. They may look like centralized repositories but they are not. We have our own local repositories, sometimes even more than one for the same project, and we use the GitHub or Bitbucket one only to sync some branches between developers. It's not what used to be with centralized systems. The only copy of the repository was on the server. Locally developers only had files sometimes with a global lock such that nobody could work on the same file at the same time. That's the real advantage of having a system like git in combination with a server like GitHub. The PRs are nice but not everybody use them. Sometimes it's only merge and push.
        palata 3y ago
        > That's the real advantage of having a system like git in combination with a server like GitHub. I would say that it is the real advantage of having a system like git, period. Right?
  - nofunsir 3y ago
    yes, and it’s worth mentioning the next step evolution after ssh was gitosis/gitolite to manage who has access to what repos on a single ssh entry point, by taking advantage of the fact that multiple authorized keys could be used for one ssh local user. enter two companies to rip off and monetize gitosis/gitolite, and eventually rewrite them into their own service, and presto, everyone has forgotten that git is both free and decentralized
- deleted 3y ago
  [deleted]
- JohnFen 3y ago
  This is exactly how I use git in my own projects.
avgcorrection 3y ago
> What's amazing is that you can also use git locally, without a server, using "git daemon". I don’t think that’s amazing. What was amazing to me was back when I couldn’t set up a Subversion repository without a “server”. Someone asks on StackOverflow about why `git push` behaves a certain way? The principle of Laziness dictates that you try to reproduce the issue with two sibling directories where one is a remote of the other one. Like they apparently do in one of Git’s integration tests: git remote add $1 up ../mirror
- tempodox 3y ago
  You can run a Subversion repository on localhost with the svnserve(1) command: https://www.visualsvn.com/support/svnbook/ref/svnserve/re/ https://www.visualsvn.com/support/svnbook/ref/svnserve/re/
  - avgcorrection 3y ago
    Yes, another kind of server.
    - Calzifer 3y ago
      But does it matter? Nowadays even my editor wants to run a server in the background to provide syntax highlighting. People generally don't seem to care and see it as progress.
      - avgcorrection 3y ago
        But what about the price of tea in China? The language servers you refer to provide a decoupled service to other programs. It has literally nothing to do with the fact that I have to (apparently—why would I even use SVN in this day and age) make a dummy repository somewhere hither or tither just so that I can version control my local-only dotfiles!
  - COMMENT___ 3y ago
    Or in serverless mode without any server at all. Just open the repository via file://.
adastra22 3y ago
Sorry, I'm honestly not trying to be snarky, but what's amazing here? `man git-daemon` displays: > git-daemon - A really simple server for Git repositories So you can "use git locally, without a server"... by using a server? Btw you don't need a daemon at all. You can just use file URLs.
e12e 3y ago
Fwiw I think fossil excels for this type of use-case.
I_complete_me 3y ago
Ok, git_noobie here. What is git http-backend [1] for then? [1] https://git-scm.com/docs/git-http-backend https://git-scm.com/docs/git-http-backend I discovered this by tabbing git ?TAB in a zsh shell and going through the alphabet. FYI - no commands starting with e, j, k, o, w, x, y or z using this method. Is there a definitive list of all git commands I wonder?
- eichin 3y ago
  If you want to use git through a web server, it's one way of doing that. (For example, if you want to use some existing http auth for your users.) You don't particularly need to do that - it's just an option; git over ssh works fine too, as does git with file: local urls (or without "remotes" at all.) Professionally, ssh auth (especially with ControlPersist) has always been the better/faster option, but that's more of a cultural thing. (My hobby workflow is to just start writing in a directory, and then after a little bit do a "git init"... and then once I have enough to pick a name, I have a "git save-project projectname" script that goes off and does a git init --bare on a homelab server and git push --set-upstream so it's now a remote. Just gradually escalating how "seriously" I'm treating it and therefore how much plumbing I bother with.)
- Jenk 3y ago
  git help -a lists all available commands. It's important to note that the git binaries are (usually) both client and server - by design what with the hole "decentralised" thing. So the default package will let you run server functionality such as the http-backend (which allows the machine you run it on to serve http(s):// schema repositories)
chrisfinazzo 3y ago
How is this different if you work alone, on one machine, and simply don't use a remote? I realize this is a bastardization of the concept, but for personal projects, it still sounds reasonable. Reads further... Eh, I guess USB drives count as separate machines in this case ¯\_(ツ)_/¯

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.
  - _ZeD_ 3y ago
    I would have used svn and a proper server. and if you start bragging about the "decentralization"... well, there is a reason anyone now uses a gitHUB, where there is a proper, centralized, version online
    - palata 3y ago
      > where there is a proper, centralized, version online Linux has a proper, centralized, version online. Still their collaboration workflow (they use the email workflow) is decentralised. I think everybody uses GitHub now because they don't know the email workflow, and it's more convenient to have one account on GitHub than having one account on every instance of GitLab you contribute to. And I guess most people only know the GitHub web interface and don't really feel like using something else. My point being that there are many reasons why everybody is using GitHub, but it does not mean that the PR workflow is better. What do you think?
      - pmontra 3y ago
        All my current customers are using Bitbucket, but it's the same. They may look like centralized repositories but they are not. We have our own local repositories, sometimes even more than one for the same project, and we use the GitHub or Bitbucket one only to sync some branches between developers. It's not what used to be with centralized systems. The only copy of the repository was on the server. Locally developers only had files sometimes with a global lock such that nobody could work on the same file at the same time. That's the real advantage of having a system like git in combination with a server like GitHub. The PRs are nice but not everybody use them. Sometimes it's only merge and push.
        palata 3y ago
        > That's the real advantage of having a system like git in combination with a server like GitHub. I would say that it is the real advantage of having a system like git, period. Right?
- nofunsir 3y ago
  yes, and it’s worth mentioning the next step evolution after ssh was gitosis/gitolite to manage who has access to what repos on a single ssh entry point, by taking advantage of the fact that multiple authorized keys could be used for one ssh local user. enter two companies to rip off and monetize gitosis/gitolite, and eventually rewrite them into their own service, and presto, everyone has forgotten that git is both free and decentralized
deleted 3y ago
[deleted]
JohnFen 3y ago
This is exactly how I use git in my own projects.

avgcorrection 3y ago

> What's amazing is that you can also use git locally, without a server, using "git daemon". I don’t think that’s amazing. What was amazing to me was back when I couldn’t set up a Subversion repository without a “server”. Someone asks on StackOverflow about why `git push` behaves a certain way? The principle of Laziness dictates that you try to reproduce the issue with two sibling directories where one is a remote of the other one. Like they apparently do in one of Git’s integration tests: git remote add $1 up ../mirror

tempodox 3y ago
You can run a Subversion repository on localhost with the svnserve(1) command: https://www.visualsvn.com/support/svnbook/ref/svnserve/re/ https://www.visualsvn.com/support/svnbook/ref/svnserve/re/
- avgcorrection 3y ago
  Yes, another kind of server.
  - Calzifer 3y ago
    But does it matter? Nowadays even my editor wants to run a server in the background to provide syntax highlighting. People generally don't seem to care and see it as progress.
    - avgcorrection 3y ago
      But what about the price of tea in China? The language servers you refer to provide a decoupled service to other programs. It has literally nothing to do with the fact that I have to (apparently—why would I even use SVN in this day and age) make a dummy repository somewhere hither or tither just so that I can version control my local-only dotfiles!
- COMMENT___ 3y ago
  Or in serverless mode without any server at all. Just open the repository via file://.

adastra22 3y ago

Sorry, I'm honestly not trying to be snarky, but what's amazing here? `man git-daemon` displays: > git-daemon - A really simple server for Git repositories So you can "use git locally, without a server"... by using a server? Btw you don't need a daemon at all. You can just use file URLs.

e12e 3y ago

Fwiw I think fossil excels for this type of use-case.

I_complete_me 3y ago

Ok, git_noobie here. What is git http-backend [1] for then? [1] https://git-scm.com/docs/git-http-backend https://git-scm.com/docs/git-http-backend I discovered this by tabbing git ?TAB in a zsh shell and going through the alphabet. FYI - no commands starting with e, j, k, o, w, x, y or z using this method. Is there a definitive list of all git commands I wonder?

eichin 3y ago
If you want to use git through a web server, it's one way of doing that. (For example, if you want to use some existing http auth for your users.) You don't particularly need to do that - it's just an option; git over ssh works fine too, as does git with file: local urls (or without "remotes" at all.) Professionally, ssh auth (especially with ControlPersist) has always been the better/faster option, but that's more of a cultural thing. (My hobby workflow is to just start writing in a directory, and then after a little bit do a "git init"... and then once I have enough to pick a name, I have a "git save-project projectname" script that goes off and does a git init --bare on a homelab server and git push --set-upstream so it's now a remote. Just gradually escalating how "seriously" I'm treating it and therefore how much plumbing I bother with.)
Jenk 3y ago
git help -a lists all available commands. It's important to note that the git binaries are (usually) both client and server - by design what with the hole "decentralised" thing. So the default package will let you run server functionality such as the http-backend (which allows the machine you run it on to serve http(s):// schema repositories)

chrisfinazzo 3y ago

How is this different if you work alone, on one machine, and simply don't use a remote? I realize this is a bastardization of the concept, but for personal projects, it still sounds reasonable. Reads further... Eh, I guess USB drives count as separate machines in this case ¯\_(ツ)_/¯