3 ms·

My number one favourite thing about Git is that is that I have a full copy of the repository history and I can work on it without talking to a central server, o

by rossy 10y ago

My number one favourite thing about Git is that is that I have a full copy of the repository history and I can work on it without talking to a central server, or any server. I can do a `git blame` or a `git bisect` without receiving a byte from the network, which is great because my internet connection is horrible. I can work on a train. I can work on an experimental feature in a branch with full history, decide it was a bad idea, delete the branch, and no one has to know about my failure. I can even share that branch between multiple machines in my house without setting up any server infrastructure. I can write shitty commit messages like 'fix the thing for real this time' and clean them up later with a rebase before I push. I can make a series of commits, convert them to a series of patches and apply them during a build script with `git am`. I can version any folder on my machine just by typing `git init`, which is especially useful for folders of config files. Also, I think Git's model of working locally encourages people to think of their commits like their code. Good Git projects have small commits, a clean history and commit messages that are like documentation (which is especially useful, because you can use blame to locally find the change relating to a line.)

caf 10y ago
Yes, I think this bit was a bit over-egged: If you work as a field tech, or on a space station, or in a submarine or something, then okay, sure, this is a huge feature for you. I'm not an astronaut or a submariner, but I do fly in the cheap seats on commercial aircraft - sometimes to places where roaming data is eye-wateringly expensive.
- cm3 10y ago
  And even if you're at a desk with a permanent internet connection, the server roundtrip is never as fast as local disk access. Having fast access to history is something I don't want to miss. On top of that, having it all locally allows for more uses like searching through history and more advanced features.
- ajdlinux 10y ago
  Just this afternoon, I went over to the cafe across the road from the office for a couple of hours to get some code review done. This cafe doesn't have WiFi - which is part of the attraction for a less-distracting environment, really. Having history available locally is fantastic!
scoot 10y ago
> I can even share that branch between multiple machines in my house without setting up any server infrastructure. What's your workflow for this?
- greggman 10y ago
  I think they mean without setting up a VCS server. You still need for the 2 machines to be able to access each other somehow, usually ssh (which is technically a server), or a file server (NFS, samba, which is also technically a server), but, many people have one or both of those running already running. If so it's just git clone ssh://name@addressOrNameOfMachine/path/to/repo or git clone path/to/shared/folder etc...
  - sevensor 10y ago
    Also, you could clone to a thumbdrive and push to / pull from there. No servers at all.
- davidbanham 10y ago
  tar cvf repo.tar .git && cp repo.tar /media/thumbdrive
- rossy 10y ago
  Yeah, like greggman said, I was mainly referring to SSH, though I've also transferred repositories with a flash drive before. I once worked on a project with a coworker where we used git daemon to pull from each other, which is technically a server, but easy to set up and we didn't have to bug the IT department about getting a real server to use. It worked surprisingly well.
Osiris 10y ago
The author conveniently ignores one important downside to centralized source control: speed. Switching branches in git is incredibly fast, specifically because you have all the history locally. The reason branching was so uncommon in SVN was because of how horribly slow it was to switch branches. > Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. The problem with that statement is that it's wrong. Every time he switched branches or made a new branch it was relying on his local copy of the repo. Sure, he makes some good points about binary blobs and submodules, but he also avoids talking about the downsides of centralized version control.

by rossy 10y ago

caf 10y ago

Yes, I think this bit was a bit over-egged: If you work as a field tech, or on a space station, or in a submarine or something, then okay, sure, this is a huge feature for you. I'm not an astronaut or a submariner, but I do fly in the cheap seats on commercial aircraft - sometimes to places where roaming data is eye-wateringly expensive.

cm3 10y ago
And even if you're at a desk with a permanent internet connection, the server roundtrip is never as fast as local disk access. Having fast access to history is something I don't want to miss. On top of that, having it all locally allows for more uses like searching through history and more advanced features.
ajdlinux 10y ago
Just this afternoon, I went over to the cafe across the road from the office for a couple of hours to get some code review done. This cafe doesn't have WiFi - which is part of the attraction for a less-distracting environment, really. Having history available locally is fantastic!

scoot 10y ago

> I can even share that branch between multiple machines in my house without setting up any server infrastructure. What's your workflow for this?

greggman 10y ago
I think they mean without setting up a VCS server. You still need for the 2 machines to be able to access each other somehow, usually ssh (which is technically a server), or a file server (NFS, samba, which is also technically a server), but, many people have one or both of those running already running. If so it's just git clone ssh://name@addressOrNameOfMachine/path/to/repo or git clone path/to/shared/folder etc...
- sevensor 10y ago
  Also, you could clone to a thumbdrive and push to / pull from there. No servers at all.
davidbanham 10y ago
tar cvf repo.tar .git && cp repo.tar /media/thumbdrive
rossy 10y ago
Yeah, like greggman said, I was mainly referring to SSH, though I've also transferred repositories with a flash drive before. I once worked on a project with a coworker where we used git daemon to pull from each other, which is technically a server, but easy to set up and we didn't have to bug the IT department about getting a real server to use. It worked surprisingly well.

Osiris 10y ago

The author conveniently ignores one important downside to centralized source control: speed. Switching branches in git is incredibly fast, specifically because you have all the history locally. The reason branching was so uncommon in SVN was because of how horribly slow it was to switch branches. > Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. The problem with that statement is that it's wrong. Every time he switched branches or made a new branch it was relying on his local copy of the repo. Sure, he makes some good points about binary blobs and submodules, but he also avoids talking about the downsides of centralized version control.