" constantly trying to dispel the idea that git is too difficult "
If that's the case, why wouldn't you concede that it is?
"The problem has always come down to the missing attempt to understand the issue"
Isn't that always the case with misunderstanding something?
That 'it's common' and 'people misunderstand the issue' is essentially proof that at least from a certain level, 'git is hard'.
- Git is very powerful. Nobody doubts this.
- Git is sometimes easier to understand when the model is well understood - yes, this is a common refrain.
But - it's still a very complex model, and the UI is bizarre + counter intuitive and as a command line, without a lot of visual reference.
Even standards and practices are not well established as there continue to be wars over idiomatic usage, arguments on HN often by 'experts' who actually make some mistakes in their argumentation.
I suspect a lot of people who think they are 'good at git' 1) don't realize how much they don't know and 2) maybe lacking in self-awareness as to how much trouble if often causes.
I've seen very smart people with very strong git skills befuddled far too often for me to believe the tool does not have problems.
The fact that 'Oh Shit Git' even exists, is in some ways problematic - because it's obviously not clear to many how to truly 'undo' things they've done. OSG could be 100x longer, easily.
This is really scary. It's not a complicated question necessarily, maybe a little specific - but - there are just so many answers, so many variables, incredible complexity in the answers.
Git has a kind of 'unbounded complexity' that allows for so, so many situations and uses cases. There really wasn't much 'Product thinking' rather, just a decade long cadence of 'let's add this feature with this flag' over and over again.
It's such an interesting case study from a Product perspective.
It may only seem that way because there are parts of the model you don't understand. There is a finite (relatively small) number of concepts necessary to mastering git.
"There is a finite (relatively small) number of concepts necessary to mastering git."
This is only partly true. The degree of variation and options in the command line actually fiddles with that 'simplicity' quite fundamentally.
Even if one has a 'clear understanding of the concepts' - the commands don't necessarily map clearly to that model. And there are so many commands, so many little variations.
Maybe you can expand a bit on this? Or point to a resource for learning the concepts?
I've tried a few tutorials about git internals before, but always get confused in the middle for some reason. I go just after git being a list with pointers where each element having a hash and what not. But still something seems to be missing in the end to make it all coherent.
>> "The problem has always come down to the missing attempt to understand the issue"
> Isn't that always the case with misunderstanding something?
No, some things are difficult. Git might be one of them, but I have no reason to believe that. It's the attempt that's missing. They most often, don't understand git, not because they tried to, and failed. But because they've never really tried to understand the problem. Skipping the part where they find the root cause, actually figured out exactly what's happening, and what's gone awry. They've only searched Stackover flow for the `git reset --hard` command they need.
> But - it's still a very complex model, and the UI is bizarre + counter intuitive and as a command line, without a lot of visual reference.
As someone who's used a lot of command line tools, I reject this out right. Git is a very simple command line tool. The difficulty is more akin to learning how to use a CLI, not necessarily git itself. Try teaching MS Word to someone while also trying to teach them to write an essay. The missing visual reference will throw people off, but that doesn't make learning how to use it harder. Instead of clicking around for the button that might do something. They have to read something, git --help is super useful. Just like F1 or clicking the help dropdown at the top.
> Even standards and practices are not well established as there continue to be wars over idiomatic usage, arguments on HN often by 'experts' who actually make some mistakes in their argumentation. I suspect a lot of people who think they are 'good at git' 1) don't realize how much they don't know and 2) maybe lacking in self-awareness as to how much trouble if often causes. I've seen very smart people with very strong git skills befuddled far too often for me to believe the tool does not have problems.
I haven't had these experiences, so I really can't comment. I have to say, I don't really believe people when they say they know and understand git. If someone says they know how to use a chainsaw, do they also know you have to oil it? Knowing how to use something isn't the same as understanding it. Which is what I want people to do....
> This is really scary. It's not a complicated question necessarily, maybe a little specific - but - there are just so many answers, so many variables, incredible complexity in the answers.
I'm not scared by this at all, so I have no idea what you're talking about.
> Git has a kind of 'unbounded complexity' that allows for so, so many situations and uses cases. There really wasn't much 'Product thinking' rather, just a decade long cadence of 'let's add this feature with this flag' over and over again.
Because git is feature rich doesn't mean much. Name a software engineering tool you think is simple/easy, and (if you try to be reasonable,) I'd be willing to bet it has nearly the same, if not more features than git does.
" I reject this out right. Git is a very simple command line tool. "
That's great, but most people would disagree, using the argument that there are rather a large number of variations of commands.
Can you think of another 'command line tool' with more complexity?
Git questions are amply popular on Stack Exchange. It's not that hard to use most other commands. All you need is -help.
"I'm not scared by this at all, so I have no idea what you're talking about."
It's 'scary' because it's ostensibly a very basic question, with apparently quite a number of varied solutions, each of them fairly complicated, and apparently not without controversy.
The second to top answer starts with: "Lots of complicated and dangerous answers here, but it's actually easy:"
If you put on your 'Product/Manager/Investor/I want to make a thing, not tinker in intellectualisms' hat for a moment, it is 'very scary'.
How can answers to simple questions about a tool be 'dangerous'? Of course, it's because some of these operations will screw up a repo, or create undue confusion. That's not good.
Why are there so many variations in answers?
Why is someone making a diagram? If someone has to 'get out the whiteboard' to answer simple tooling questions, then there are added levels of abstraction - which could be fine - but why on earth is that necessary?
Why are people having to go down rabbit holes of 'possible dangerous operations' to do something simple?
There are literally 62 addendums and comments to the top answer!
This is the 'opposite' of a 'good product' and the opposite of 'easy' - it has red flags all over it to the point wherein I'm thinking that I wish there were administrative options to make sure bad outcomes cannot happen, to start.
Complexity is costly, expensive, risky. Git is already a 'secondary factor' in making a product, the software being the 'primary factor'. So we're having to invest in knowledge, risk, problems etc. with 'a tool to help the tool' ... and when we run into serious problems, who do we call?
I don't want my devs to be tripping over themselves, falling into holes, possibly unrecoverable situations, spending time solving problems they should not have to.
Does the problem we are trying to solve imply this kind of necessary complexity? I don't think so.
"Name a software engineering tool you think is simple/easy"
So the question really is - what kind of complexity (magnitude, necessary complexity vs. arbitrary, required abstractions etc.) does a tool provide vs. the value provided - that is the question.
Git provides quite a lot of power, but its constrained by its own complexity - for very standard operations, it's quite easy. But beyond that it's a mine field.
There are literally people on this thread indicating that they don't even allow themselves to use commands they don't know well. There are ample stories of people getting them into problems they can't get out of, loss of code etc.. Where else does this happen for tooling?
There is a 'Golden Rule of Git' of something never to do - this to me is a huge Red Flag. Why the hell is something that 'should never be done' - even doable?!? This to me is a perfect example of the 'unbounded' nature of the complexity.
Finally - I have actually never met a Git expert. All the smart people I know who are 'strong in Git' are often befuddled in various situations. Yes, that happens in software, but it doesn't need to happen with our code management systems.
Since you asked for an example: awk may be more complicated than git.
> Why is someone making a diagram? If someone has to 'get out the whiteboard' to answer simple tooling questions, then there are added levels of abstraction - which could be fine - but why on earth is that necessary?
It's an inherent aspect of distributed version control that the history of your repository forms a graph, and therefore drawing diagrams can be helpful.
Please take the following as the friendly advice it's meant to be: the fact that you even ask this question will suggest to every advanced user of DVCS that you really don't understand what you're talking about. Which is fine, if you have the humility to accept it and improve.
Please take the following friendly advice: if you don't know the difference between a 'command line tool' and a 'programming language' - then maybe you don't know what you're talking about. It's ok, if you have some humility, you can improve and overcome.
FYI I'm well aware that systems such as CVS have 'abstractions' that diagrams could possibly help. That said 'diagrams' are relate the the 'inherent abstractions' in many things, and yet they are used very seldom in Stack Exchange.
The fact is - git is quite obviously very complicated, more complicated than it needs to be, and poses risks that most other tools do not.
The bizarre myopia of those not willing to concede that, and the inherent risks is problematic.
It speaks to a specific kind of intellectual arrogance within CompSci and it's a huge blind spot for the profession.
Every git question - even the most mundane - is a rabbit hole:
"What's the difference between Git Pull and Git Fetch?" [2]
That should be easy enough - but no - there is a 35 comments (only one of the many answers) to argue about the specific nature of what is happening, and no full agreement on some material things.
This is all exemplary of a 'bad product'. A 'good product' would provide a definition, and a few comments on possible corner cases - and that's it.
Git is what happens when you take a 'very powerful, but complicated concept' - and then don't manage it as a product, rather, just lazily throw complex command lines on the fire and let it stir. We are wasting a lot of time on Git.
The reason there's so much discussion is because while the question seems simple, it's ill-posed and there are several distinct things they could actually want to be doing: do they want to make a commit which undoes another commit, do they want to check out an older version to either test something or make a branch, or do they want to remove some commits they made accidentally? All of these are reasonable things to want to do and the only reason the answer may seem easier for other systems is because for some of those options either can't do them or they are so difficult and risky you're only going to do them if you really have to. That's why the top answer gives three different options based on different possible interpretations of the question. The rest of the discussion is either people who think that some of those options shouldn't exist for mostly ideological reasons or people who haven't taken the time to understand what each of those options actually mean.
If all you want from a VCS is a snapshot of each part of history, git can do that (and will actually do it better than a more traditional option like SVN because it doesn't hide merges by doing them on your working directory before you commit), but ultimately there's a lot of value in doing more and if you want to exploit that you should understand how the VCS represents your code and how to use it, not paste together advice from other people on the internet who may not fully understand it themselves. I agree the git UI has problems, mostly relating to naming things and the fact that many commands have convenience options which mean they invoke actions which are different from their base operation (like git checkout -b <name>, which is basically a way of doing git branch <name> followed by git checkout <name>. It would make more sense if this was just the way git branch operated by default, or at least as a flag on git branch instead of git checkout). The underlying model git presents is really not hard to learn (and it helps a hell of a lot when googling how to do something because you can be precise about it) but it's where people tangle themselves most in knots because they think it's either too difficult or not worth understanding, and it's wrong on both counts because it will cost them hugely in time and stress.
" there are several distinct things they could actually want to be doing"
Yes - I get that - but this is my point.
It's such a complicated tool (or rather, specifics are not obvious) that people don't even know how to ask questions.
This is part of my point.
Ambiguous questions, ambiguous answers, a real propensity for people to be giving really bad answers.
This is endemic with Git, more so than I've seen with anything else.
I sometimes wonder if Git should should actually be used with some kind of visual representation as a default standard - and that our propensity for 'command line interface' as the de-facto means of real interface with computers may not be appropriate to communicating 'what is going on'.
Much like people fuss desperately over road signs, human factors in automobiles ... perhaps we should be thinking in these terms much more with this tool.
I agree on the GUI front: git is a lot more comprehensible when you have a graphic representation of the commit graph at all times. This is my default way of interacting with git: even if I'm using the CLI to mutate the repository, I have a GUI open to view the repo.
If that's the case, why wouldn't you concede that it is?
"The problem has always come down to the missing attempt to understand the issue"
Isn't that always the case with misunderstanding something?
That 'it's common' and 'people misunderstand the issue' is essentially proof that at least from a certain level, 'git is hard'.
- Git is very powerful. Nobody doubts this. - Git is sometimes easier to understand when the model is well understood - yes, this is a common refrain.
But - it's still a very complex model, and the UI is bizarre + counter intuitive and as a command line, without a lot of visual reference.
Even standards and practices are not well established as there continue to be wars over idiomatic usage, arguments on HN often by 'experts' who actually make some mistakes in their argumentation.
I suspect a lot of people who think they are 'good at git' 1) don't realize how much they don't know and 2) maybe lacking in self-awareness as to how much trouble if often causes.
I've seen very smart people with very strong git skills befuddled far too often for me to believe the tool does not have problems.
The fact that 'Oh Shit Git' even exists, is in some ways problematic - because it's obviously not clear to many how to truly 'undo' things they've done. OSG could be 100x longer, easily.
Have a look here:
https://stackoverflow.com/questions/4114095/how-do-i-revert-...
This is really scary. It's not a complicated question necessarily, maybe a little specific - but - there are just so many answers, so many variables, incredible complexity in the answers.
Git has a kind of 'unbounded complexity' that allows for so, so many situations and uses cases. There really wasn't much 'Product thinking' rather, just a decade long cadence of 'let's add this feature with this flag' over and over again.
It's such an interesting case study from a Product perspective.