4 ms·

I've said this before, but the business leadership, and tech leadership, need to think carefully about whether or not they need all of the power of Git. This su

I've said this before, but the business leadership, and tech leadership, need to think carefully about whether or not they need all of the power of Git. This sums up my concerns: ----------------------- Here are some minor failure modes I’ve seen with Git: 1. a branch that stays open for many months, perhaps even a year (for instance, at Maternity Neighborhood) 2. data is erased for good because someone makes a mistake while using rebase 3. a developer introduces a new bug while trying to resolve a merge conflict 4. widespread but fine-grained cherry picking leaves the team unclear about what’s been merged and what has not been merged 5. a developer makes a change in the wrong branch because they forgot what branch they were in 6. a developer is unable to recover a stash because they forgot where they were when they created the stash, or they simply forget that they have work in a stash 7. developers confused by working in an unattached commit, after a botched attempt to revert 8. a developer feels the need to delete the repo from their harddrive and clone it again, because the whole repo got into a state that they seemed unable to resolve 9. the “blame” command is nearly useless — maybe its because we never know in which branch a given change was made, finding who made a mistake is very difficult 10. developers get confused about which branch will be deployed (I see this especially in shops that have lots of repos for lots of small apps, and use different Git workflow strategies for the different repos, often because different programmers or different teams control the different repos) 11. developers push their changes to “origin” but forget to push to “upstream” or vice versa. But all of that stuff is trivial compared to the major flaw: Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion. http://www.smashcompany.com/business/business-productivity-has-been-undermined-by-the-hubris-and-power-grabbing-of-elite-computer-programmers http://www.smashcompany.com/business/business-productivity-h...

rootlocus 9y ago
> 2. data is erased for good because someone makes a mistake while using rebase No. Just no. Please stop spreading FUD like it's candy. Git only deletes commits after a GC, which won't erase commits from reflog and will keep unreferenced commits for at least a month before deleting them. And rebasing generates new commits, leaving the old ones exactly how they were. If somebody lost a commit after a rebase, and nobody nearby could help them recover it, they should consider spending a few hours learning about git. I've been using git for 4 years both at work (with a team of 40+ people) and at home, without ever having any of the problems listed here (except 3 which has nothing to do with git). It takes a few hours, maybe a few days to understand how git works and how to use it. Instead of blaming the tools, you (and your team) should probably learn how to use them.
- lkrubner 9y ago
  "Instead of blaming the tools, you (and your team) should probably learn how to use them." From the essay: -------------------- And Git is intimidating, not just to non-technical staff, but also to inexperienced programmers. In How To Destroy A Tech Startup In Three Easy Steps I talk about Sital, and his unwillingness to commit things to Git. He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git. He went a month without making a commit, and then he only did so because I insisted. After I put a lot of pressure on him, he got to the point where he would make one commit a day, at night, when he was stopping for the day. He would commit to the master branch, because he was confused how to handle different branches. When there was a merge conflict, I would resolve it for him. We worked together for 6 months, and in that time he learned a great deal about a lot of important topics, but he never really learned how to use Git, because it was a low priority, for both him and our CEO.
  - rootlocus 9y ago
    > He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git. Git is something that you can use on almost any project, with any team, at any company. It's something you need to use if you want to contribute to open source. Aside from your programming language of choice, it's probably the second most useful tool you should be learning as a software developer. You're telling me a developer was too busy learning "other technologies", and in 6 months he couldn't be bothered (or was too afraid) to spend one or two hours going through a simple course about git? By that argument, he probably couldn't be bothered to learn how separate concerns into classes or how to use refactoring or write tests. What other things didn't he have time for? Unwillingness to learn is not an excuse. > he never really learned how to use Git, because it was a low priority, for both him and our CEO. I think it was more of a lower priority for your CEO than Sital. Learning git was something that benefited him more than it benefited the company. I still have issues with your attitude, because it can be applied to anything useful in software development, but management might take issue with. Writing tests? Who needs them? The CEO doesn't care so they're low priority. Refactoring? Waste of time. Management wants shiny features not code quality. Developers have tried really hard to convince management that some overhead is needed to keep the quality high and maintenance easy. Your attitude is the exact opposite.
teilo 9y ago
Most of these have nothing to do with git, but are true of any distributed repository. At that point, your argument becomes: distributed repositories are bad for business. Then there's this: > Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion. What rubbish. The features of subversion are a subset of git, and the git equivalents are easy to learn. For a svn user, there's literally only a single additional command they need to know: git push.
- ryanbrunner 9y ago
  To be fair, git is the first VCS I've ever used where there was any real learning curve at all for normal, everyday use. I don't recall anyone ever really teaching me subversion, outside of maybe 5 minutes walking through the GUI. With git I feel like it probably took a few months of regular use before I felt comfortable with it. That doesn't mean that I'd go back to subversion, but I don't think it's fair to say it's as easy to use.
  - DougBTX 9y ago
    I remember trying to do merges in SVN years ago, it was so hard my team agreed to just never make new branches. Git it so much easier to use, it seems hard to compare.
    - ryanbrunner 9y ago
      For branching / administration you're probably right. Typically though, subversion workflows would involve administrators doing most of the heavy lifting of branching / merging and everyone else working against those - for those users Subversion was absolutely easier.
- icebraining 9y ago
  The features of subversion are a subset of git Well, except for locking, which I hear is useful for people working with hard-to-merge files.
- 9y ago
ryanbrunner 9y ago
I'm not necessarily the biggest git fan in the world, but here's some refutations to some of these concerns: > 1. a branch that stays open for many months, perhaps even a year (for instance, at Maternity Neighborhood) This is more of a workflow question than a VCS question, and would be true of any VCS that allows branching (i.e. anything remotely close to a modern VCS) > 2. data is erased for good because someone makes a mistake while using rebase Data isn't permanently removed from rebasing, you can still get at it with the reflog. If you discovered the problem months later, I suppose that could happen. checkout and reset --hard can irrecobably destroy uncomitted data (as can clean, but that's more obvious and has appropriate guardrails) > 4. widespread but fine-grained cherry picking leaves the team unclear about what’s been merged and what has not been merged Overuse of cherry-picking feels like a workflow smell to me, but even still, you shouldn't need to care. Merging the entire branch will work fine if some of the contents have been cherry-picked previously. > 5. a developer makes a change in the wrong branch because they forgot what branch they were in True of any VCS with branching. > 6. a developer is unable to recover a stash because they forgot where they were when they created the stash, or they simply forget that they have work in a stash I'll agree with you here, I think stash is a bit of a footgun and almost never makes sense to use if the stashed contents are going to live for longer than a minute or two. But this is easily addressable with workflow, don't use stash for anything other than an extremely temporary holding place. > 7. developers confused by working in an unattached commit, after a botched attempt to revert Git is generally not great about warning you about dangerous operations or things you shouldn't be doing. Running against a detached HEAD is not one of those things, you'd have to be willfully ignoring what it's telling you to not realize that this isn't a safe thing to do. > 8. a developer feels the need to delete the repo from their harddrive and clone it again, because the whole repo got into a state that they seemed unable to resolve I will agree that git could make it easier to say "just get me back to origin, i give up" > 9. the “blame” command is nearly useless — maybe its because we never know in which branch a given change was made, finding who made a mistake is very difficult Blame isn't great, but it sucks in precisely the same way it sucks in any VCS. Just seeing who last committed a line often isn't enough information. It would be cool to see an alternative here, but I don't see many better alternatives around. It sounds like in general, this is more a concern with dealing with branches and branching, which is totally fair. If simple trunk-based development works for you, branches are an unnecessary addition. But there's no reason you have to use all these git features. You can happily have everyone just work against master and never need to think about branches (in that mode the various Git GUIs will probably be more than adequate as well). I do agree that git tutorials tend to focus on a more advanced branching / rebase focused workflow, and that simpler resources for less technically minded folks would be handy.
vijucat 9y ago
Great list. You'll face a predictable backlash by git fanatics, but the fact remains that git's surface area / complexity is way beyond the needs or wants of non-technical users. This is another good rebuttal to the supposed shortcomings of svn which make git necessary: https://svnvsgit.com/ https://svnvsgit.com/ You're right about the joy that end users feel when they learn TortoiseSVN and are able to put what they see as "infinite undo" into practice so easily. There was a sarcastic list of git koans, too, somewhere, which I found funny.
- rootlocus 9y ago
  Almost everything on that list is wrong, but if I point something out (because I actually learned how it works), I'm just a predictable git fanatic? How is that different from burying your head in the sand?
  - lkrubner 9y ago
    because I actually learned how it works The argument is focused on those who can not learn how it works. See some of the other excerpts from the essay that are in this thread. Also, it's important to note that everything on that list is something that actually happened. Be careful about comparing your advanced skills to people with less skill than you.
    - rootlocus 9y ago
      > The argument is focused on those who can not learn how it works. If you're a software developer who uses branches and merges, you absolutely should learn how it works. If you're an artist, git is not for you. It can neither store large binary files efficiently, nor merge them. There are other VCS that supposedly can, but I haven't tried them. > Also, it's important to note that everything on that list is something that actually happened. I can assure you, no data was permanently lost. What did happen is somebody couldn't find it, because they didn't know where to look. And I argue they should have, because git is not really that hard to learn (as a developer).

rootlocus 9y ago

> 2. data is erased for good because someone makes a mistake while using rebase No. Just no. Please stop spreading FUD like it's candy. Git only deletes commits after a GC, which won't erase commits from reflog and will keep unreferenced commits for at least a month before deleting them. And rebasing generates new commits, leaving the old ones exactly how they were. If somebody lost a commit after a rebase, and nobody nearby could help them recover it, they should consider spending a few hours learning about git. I've been using git for 4 years both at work (with a team of 40+ people) and at home, without ever having any of the problems listed here (except 3 which has nothing to do with git). It takes a few hours, maybe a few days to understand how git works and how to use it. Instead of blaming the tools, you (and your team) should probably learn how to use them.

lkrubner 9y ago
"Instead of blaming the tools, you (and your team) should probably learn how to use them." From the essay: -------------------- And Git is intimidating, not just to non-technical staff, but also to inexperienced programmers. In How To Destroy A Tech Startup In Three Easy Steps I talk about Sital, and his unwillingness to commit things to Git. He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git. He went a month without making a commit, and then he only did so because I insisted. After I put a lot of pressure on him, he got to the point where he would make one commit a day, at night, when he was stopping for the day. He would commit to the master branch, because he was confused how to handle different branches. When there was a merge conflict, I would resolve it for him. We worked together for 6 months, and in that time he learned a great deal about a lot of important topics, but he never really learned how to use Git, because it was a low priority, for both him and our CEO.
- rootlocus 9y ago
  > He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git. Git is something that you can use on almost any project, with any team, at any company. It's something you need to use if you want to contribute to open source. Aside from your programming language of choice, it's probably the second most useful tool you should be learning as a software developer. You're telling me a developer was too busy learning "other technologies", and in 6 months he couldn't be bothered (or was too afraid) to spend one or two hours going through a simple course about git? By that argument, he probably couldn't be bothered to learn how separate concerns into classes or how to use refactoring or write tests. What other things didn't he have time for? Unwillingness to learn is not an excuse. > he never really learned how to use Git, because it was a low priority, for both him and our CEO. I think it was more of a lower priority for your CEO than Sital. Learning git was something that benefited him more than it benefited the company. I still have issues with your attitude, because it can be applied to anything useful in software development, but management might take issue with. Writing tests? Who needs them? The CEO doesn't care so they're low priority. Refactoring? Waste of time. Management wants shiny features not code quality. Developers have tried really hard to convince management that some overhead is needed to keep the quality high and maintenance easy. Your attitude is the exact opposite.

teilo 9y ago

Most of these have nothing to do with git, but are true of any distributed repository. At that point, your argument becomes: distributed repositories are bad for business. Then there's this: > Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion. What rubbish. The features of subversion are a subset of git, and the git equivalents are easy to learn. For a svn user, there's literally only a single additional command they need to know: git push.

ryanbrunner 9y ago
To be fair, git is the first VCS I've ever used where there was any real learning curve at all for normal, everyday use. I don't recall anyone ever really teaching me subversion, outside of maybe 5 minutes walking through the GUI. With git I feel like it probably took a few months of regular use before I felt comfortable with it. That doesn't mean that I'd go back to subversion, but I don't think it's fair to say it's as easy to use.
- DougBTX 9y ago
  I remember trying to do merges in SVN years ago, it was so hard my team agreed to just never make new branches. Git it so much easier to use, it seems hard to compare.
  - ryanbrunner 9y ago
    For branching / administration you're probably right. Typically though, subversion workflows would involve administrators doing most of the heavy lifting of branching / merging and everyone else working against those - for those users Subversion was absolutely easier.
icebraining 9y ago
The features of subversion are a subset of git Well, except for locking, which I hear is useful for people working with hard-to-merge files.
9y ago

ryanbrunner 9y ago

I'm not necessarily the biggest git fan in the world, but here's some refutations to some of these concerns: > 1. a branch that stays open for many months, perhaps even a year (for instance, at Maternity Neighborhood) This is more of a workflow question than a VCS question, and would be true of any VCS that allows branching (i.e. anything remotely close to a modern VCS) > 2. data is erased for good because someone makes a mistake while using rebase Data isn't permanently removed from rebasing, you can still get at it with the reflog. If you discovered the problem months later, I suppose that could happen. checkout and reset --hard can irrecobably destroy uncomitted data (as can clean, but that's more obvious and has appropriate guardrails) > 4. widespread but fine-grained cherry picking leaves the team unclear about what’s been merged and what has not been merged Overuse of cherry-picking feels like a workflow smell to me, but even still, you shouldn't need to care. Merging the entire branch will work fine if some of the contents have been cherry-picked previously. > 5. a developer makes a change in the wrong branch because they forgot what branch they were in True of any VCS with branching. > 6. a developer is unable to recover a stash because they forgot where they were when they created the stash, or they simply forget that they have work in a stash I'll agree with you here, I think stash is a bit of a footgun and almost never makes sense to use if the stashed contents are going to live for longer than a minute or two. But this is easily addressable with workflow, don't use stash for anything other than an extremely temporary holding place. > 7. developers confused by working in an unattached commit, after a botched attempt to revert Git is generally not great about warning you about dangerous operations or things you shouldn't be doing. Running against a detached HEAD is not one of those things, you'd have to be willfully ignoring what it's telling you to not realize that this isn't a safe thing to do. > 8. a developer feels the need to delete the repo from their harddrive and clone it again, because the whole repo got into a state that they seemed unable to resolve I will agree that git could make it easier to say "just get me back to origin, i give up" > 9. the “blame” command is nearly useless — maybe its because we never know in which branch a given change was made, finding who made a mistake is very difficult Blame isn't great, but it sucks in precisely the same way it sucks in any VCS. Just seeing who last committed a line often isn't enough information. It would be cool to see an alternative here, but I don't see many better alternatives around. It sounds like in general, this is more a concern with dealing with branches and branching, which is totally fair. If simple trunk-based development works for you, branches are an unnecessary addition. But there's no reason you have to use all these git features. You can happily have everyone just work against master and never need to think about branches (in that mode the various Git GUIs will probably be more than adequate as well). I do agree that git tutorials tend to focus on a more advanced branching / rebase focused workflow, and that simpler resources for less technically minded folks would be handy.

vijucat 9y ago

Great list. You'll face a predictable backlash by git fanatics, but the fact remains that git's surface area / complexity is way beyond the needs or wants of non-technical users. This is another good rebuttal to the supposed shortcomings of svn which make git necessary: https://svnvsgit.com/ https://svnvsgit.com/ You're right about the joy that end users feel when they learn TortoiseSVN and are able to put what they see as "infinite undo" into practice so easily. There was a sarcastic list of git koans, too, somewhere, which I found funny.

rootlocus 9y ago
Almost everything on that list is wrong, but if I point something out (because I actually learned how it works), I'm just a predictable git fanatic? How is that different from burying your head in the sand?
- lkrubner 9y ago
  because I actually learned how it works The argument is focused on those who can not learn how it works. See some of the other excerpts from the essay that are in this thread. Also, it's important to note that everything on that list is something that actually happened. Be careful about comparing your advanced skills to people with less skill than you.
  - rootlocus 9y ago
    > The argument is focused on those who can not learn how it works. If you're a software developer who uses branches and merges, you absolutely should learn how it works. If you're an artist, git is not for you. It can neither store large binary files efficiently, nor merge them. There are other VCS that supposedly can, but I haven't tried them. > Also, it's important to note that everything on that list is something that actually happened. I can assure you, no data was permanently lost. What did happen is somebody couldn't find it, because they didn't know where to look. And I argue they should have, because git is not really that hard to learn (as a developer).