Hacker News new | comments | show | ask | jobs | submit login

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-h...




> 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.


>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.

GIT is the only source control system where you can completly loose commited data by actions (or commands) available the non-admin user. It's funny to see that this is considered a "feature" and not a design failure.


> completly loose commited data

Except the whole point is that you can't completely lose commited data, even if you tried really hard. And the solution to the problem was `git reflog` which shows the history of the HEAD.


"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.


> 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.


* Your attitude is the exact opposite. *

You setting your theory against my lived experience. If you want to understand the situation more fully, you can read How To Destroy A Tech Startup In Three Easy Steps:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

I did my best to re-create the extent to which decisions were driven by panic and the pressure of time.

Please note, every company in the world has a finite amount of time, and a finite amount of money. You can argue that a company should hire people with more experience, but people with more experience will be more expensive, so you will end up with less people. Or you can argue that a company should hire more people, of less experience, and then train them. Training takes time, so in this case you are trading time for money.

All of these strategies work, but in different circumstances. In the circumstances that I faced in 2015, described in the book, I advocated for the strategy of less people, of a higher skill level. I was, however, outvoted, which is a reality of corporate life.

It is relatively rare that a company follows an ideal strategy. What I see instead is constant course correction, often with a bit of a lag, so that the company ends up having the ideal strategy for dealing with the situation that it faced 6 months ago, which is not necessarily the ideal strategy for what it is facing now.

Business tends to be chaotic. The Platonic Ideal of computer programming needs to be adjust to the real realities that businesses face.

To be clear, Sital's attitude was a major problem, and myself and co-workers advocated that he be fired. But management kept him on, and I was given the responsibility of covering for the gaps in his knowledge. I was not happy about this, but this is a reality of business: we often have to accept that a decision has been made that we strongly disagree with, and then we need to somehow make the best of it.


Well, I see you're adding more and more constraints to suit your point of view. First you attacked git by pointing out some flaws that were only just about people not knowing how it worked. Then you gave a more specific example, where actually, it was in the company's best interest to hire a novice developer who didn't have time to learn git, because he was pressured into focusing on whatever the CEO wanted. Then you argued that really, companies can't hire good people, or train them, or use good practices and we should just use the path of least resistance. At the end of the argument, it wasn't really about git.

The issue you have with git, is that untrained developers have a hard time using it. Which brings me back to my original comment. It really doesn't take long to train someone to use git. And you can choose whatever flow you want. That's the beauty of it. If the company hires lower skill people, you can just guide choose a branching mode suited for their needs. They don't even need to use branches. Or just teach them to use an UI. But please don't teach them SVN.


You don't give a reason for this:

But please don't teach them SVN

Why would you say this?

You also say:

If the company hires lower skill people, you can just guide choose a branching mode suited for their needs

If the company has lower skill people, why not go with the technology that requires less skill? This seems like an obvious step.


Because SVN is painfully slow, bloated and almost nobody uses it anymore. You'd be doing them a disservice by teaching them a technology they most likely won't be able to take with them to their next job.


This is simply untrue:

"The issue you have with git, is that untrained developers have a hard time using it."

Please re-read my first post, up above, which started this thread. I wrote:

"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."


Ok, I agree, attacked your weakest argument, which you specifically marked as being trivial flaws. So to address your actual issue:

> Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion.

Why is it hard for them to use git? For simple use cases, git can be as easy as commit & push. No need for branches. There are even UIs which allow you to easily make commits and see the log [1]. If more people work together and conflicts arise, I honestly don't know how SVN is better at solving them.

[1] https://www.gitkraken.com/


"Why is it hard for them to use git? "

All I can do is quote what you wrote in a different comment:

"If you're an artist, git is not for you."


> Sital's attitude was a major problem

Would it be the best if Sital never committed his changes? That way he would not be able to hurt your project and you would be able to fire Sital sooner.


My leadership philosophy is "fire fast". I shouldn't have to jump through a bunch of hoops to fire someone, at least not under the rules that hold sway in the USA. Obviously the approach needs to be adjusted to fit with the laws of whatever nation you might be in. But in the USA, the law is lenient towards leadership when leadership wants to fire someone. Therefore, I should have been able to simply fire Sital. Then we would have hired someone good.


About this:

"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."

It is frustrating that you continue to take your advanced skills for granted. It is frustrating that you can not see what should be an obvious fact: that your skills are above average and therefore it is a mathematical fact that most people have less skill than you, and their lack of skill is a real world business situation that needs to be dealt with realistically. And more so, for the rest of your career your skills will continue to develop, so the gap between you and the average will continue to grow, and therefore the damage that you can do will continue to grow, if you fail to recognize that you are above average.

I can assure that I've seen data lost forever because of "git rebase". It doesn't matter that someone with your skills could have saved the situation. You were not there, therefore your skills don't matter! It is very important that you see this, or you will never be able to give accurate advice to business leaders.

If the leadership of a company decided to hire people with a skill level of x, then they should not also use a technology that requires a skill level of x + 1. You can reasonably tell them "For what you are trying to do, you should hire people with a skill level of x + 1." That is exactly what I did in the situation that I describe here:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

But sometimes the business leadership will disagree with you. They may have terrible reasons, but if you can not get them to change their minds, then you need to deal with the consequences of their bad decisions. At which point it makes sense to advocate for a technology that only requires a skill level of x.

[ EDIT TO ADD ]

I'll point out that you are demonstrating a classic case of the Dunning–Kruger effect. In particular:

"the miscalibration of the highly competent stems from an error about others."

That is, you have above average IQ and skill, therefore you perceive things to be easy, which are in fact not easy for the average.

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

You are an elite programmer. Try to avoid acting like the kind elite programmer that I criticized in "Business productivity has been undermined by the hubris and power-grabbing of elite computer programmers".


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/

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.


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?


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.


> 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).


If you're an artist, git is not for you.

Exactly. That is the entire argument. From the essay:

------

I agree, Git is amazing and very powerful. What I’m suggesting is that we should recognize that it has a very high cost. It might empower complex workflows for sophisticated teams of experienced computer programmers, but it exiles the rest of the staff, and this has significant productivity costs.

...Git is very powerful? I’m willing to go along with that line of thought so long as we all understand that using a tool that is more powerful than needed can lead to problems.

http://www.smashcompany.com/business/business-productivity-h...

[ EDIT ]

Also, this bit from the essay might make the argument more clear:

For many years, I had a refrain which I gave as advice to each client I worked with: “Your software developers are expensive, so try to shift work away from them.” Ideally, software developers should only do work that relies on skills that no one else has. If a task can be done by a graphic designer, then it should be done by a graphic designer, because generally graphic designers are paid less than software developers (obviously not in all cases, but most of the time). I co-founded a startup in 2002, and I stayed with it till 2008, and we ran a team of 8 people using this principle: push work to the less skilled people, if they can handle it. Save the tough stuff for the computer programmer. We had great success with this style of work.


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.


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.


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.


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.


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.


distributed repositories are bad for business.

If you read the whole essay, you will see that "distributed repositories are bad for business" is exactly the argument being made.


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.


* there's no reason you have to use all these git features *

If you are not using all of the Git features, then why use Git? Why not use something simple, like Subversion? As I wrote in the linked essay:

-------------------

When I list these complaints for developers, most of them respond “You are complaining about Git’s power. The stuff you list isn’t really a flaw, rather those are all examples of how amazing Git is. It is flexible enough that you can do almost anything with it.”

I agree, Git is amazing and very powerful. What I’m suggesting is that we should recognize that it has a very high cost. It might empower complex workflows for sophisticated teams of experienced computer programmers, but it exiles the rest of the staff, and this has significant productivity costs. 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.

Git is very powerful? I’m willing to go along with that line of thought so long as we all understand that using a tool that is more powerful than needed can lead to problems.

http://www.smashcompany.com/business/business-productivity-h...


Because git is magnitudes of times faster, and it's the most widespread VCS in the world at the moment.


Those are weak reasons, if Git is the wrong choice for the team.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: