3 ms·

I completely agree. Git is a product of its requirements. It's not perfect, but it gets the job done, and obviously it does it pretty well.

quicklime 5y ago
Products don't have requirements, users have requirements :) The requirements of Linus and the kernel developers are completely different from the requirements of the vast majority of users of Git, who are using it in small teams in a centralized way. I would argue that the only benefit that this decentralization gives is a local cache, which makes things nice and fast. Most users don't need to be able to create branches easily (code review tools already let you do that, effectively) and it's just given people enough rope to hang themselves (e.g. GitFlow). IMO the worst aspect of this needless complexity is having to explain to people "you've got 1) the branch central repo, 2) your local copy of that branch, and 3) your local branch". It gets even more complicated when personal forks come into the picture, as there are just so many copies of things to manage or trip over. Try explaining to a junior developer why "git fetch" takes two arguments ("origin" and "master") while "git rebase" takes just one: "origin/master".
Frost1x 5y ago
I'm not sure it's so obvious that it does it well. The thing about the tech industry is there's a lot of cargo cult and leader/follower mentality. There are plenty of shops that use git just because every other shop uses git. Chances are, most of them don't need anything nearly as complex as Git and other version management approaches for their project would suffice just as well. It's sort of how a lot of shops decide they need to incorporate 'AI' into everything, or they need to use microservices and Kubernetes to solve their problem. Some of it is just resume driven development but a lot of it is just observing and following trends.
- occoder 5y ago
  > The thing about the tech industry is there's a lot of cargo cult and leader/follower mentality. > Some of it is just resume driven development but a lot of it is just observing and following trends. Couldn't agree more. That's exactly what I think happened with git.
framecowbird 5y ago
Why the while "first stage, then commit" workflow though? Wouldn't it be simpler to just commit?
- andreareina 5y ago
  One of the ways I use the staging area is as an ephemeral wip commit: I've got a change that runs and gets me incrementally closer to the desired result, but isn't yet an atomic commit. Changes to that state can be built upon, undone etc until I've got something I'm happy to commit.
- abstract_put 5y ago
  I often have local changes that I do not want represented in my commit (e.g. that code isn't done yet), so what would I do with those changes? One solution might be to stash them, select files while doing a commit, or otherwise put them aside, but that feels like reinventing the stage-then-commit workflow. That said, adding an alias for adding everything and committing it in one shot seems like a worthwhile quality of life change.
- emodendroket 5y ago
  I find it's common that I want to change stuff in my local dev environment with changes I don't actually wish to commit -- let's say hardcoding to some folder on my local machine in a configuration file, or something like that.

quicklime 5y ago

Products don't have requirements, users have requirements :) The requirements of Linus and the kernel developers are completely different from the requirements of the vast majority of users of Git, who are using it in small teams in a centralized way. I would argue that the only benefit that this decentralization gives is a local cache, which makes things nice and fast. Most users don't need to be able to create branches easily (code review tools already let you do that, effectively) and it's just given people enough rope to hang themselves (e.g. GitFlow). IMO the worst aspect of this needless complexity is having to explain to people "you've got 1) the branch central repo, 2) your local copy of that branch, and 3) your local branch". It gets even more complicated when personal forks come into the picture, as there are just so many copies of things to manage or trip over. Try explaining to a junior developer why "git fetch" takes two arguments ("origin" and "master") while "git rebase" takes just one: "origin/master".

Frost1x 5y ago

I'm not sure it's so obvious that it does it well. The thing about the tech industry is there's a lot of cargo cult and leader/follower mentality. There are plenty of shops that use git just because every other shop uses git. Chances are, most of them don't need anything nearly as complex as Git and other version management approaches for their project would suffice just as well. It's sort of how a lot of shops decide they need to incorporate 'AI' into everything, or they need to use microservices and Kubernetes to solve their problem. Some of it is just resume driven development but a lot of it is just observing and following trends.

occoder 5y ago
> The thing about the tech industry is there's a lot of cargo cult and leader/follower mentality. > Some of it is just resume driven development but a lot of it is just observing and following trends. Couldn't agree more. That's exactly what I think happened with git.

framecowbird 5y ago

Why the while "first stage, then commit" workflow though? Wouldn't it be simpler to just commit?

andreareina 5y ago
One of the ways I use the staging area is as an ephemeral wip commit: I've got a change that runs and gets me incrementally closer to the desired result, but isn't yet an atomic commit. Changes to that state can be built upon, undone etc until I've got something I'm happy to commit.
abstract_put 5y ago
I often have local changes that I do not want represented in my commit (e.g. that code isn't done yet), so what would I do with those changes? One solution might be to stash them, select files while doing a commit, or otherwise put them aside, but that feels like reinventing the stage-then-commit workflow. That said, adding an alias for adding everything and committing it in one shot seems like a worthwhile quality of life change.
emodendroket 5y ago
I find it's common that I want to change stuff in my local dev environment with changes I don't actually wish to commit -- let's say hardcoding to some folder on my local machine in a configuration file, or something like that.