Usability. I've used git for years with libgit2, git2go, various Python libraries, etc. Git is very complicated and there is no easy way to use it programmatically, nor is is the CLI always straight forward. git pull upstream master doesn't have the same syntax as git checkout upstream/master. There are the standard commands and the porcelain commands, when to use which and which solves the proper problem? These things may be evident to me, but to younger devs? It's black magic with a side of voodoo. I actually got my current job helping someone get unstuck from a git problem (no joke, ask me about it sometime)...
No centrality. Git succeeds over Subversion because of it's lack of centrality, but while we've all agreed upon Github as the OSS standard, what happens when Github is unavailable? Granted, this problem exists for Subversion, but I know I'd like to see a multi-master, peered server with consistency to help solve this problem. Granted, this solves one problem and potentially creates others, but availability is important if you communally centralise. In my mind, Git's lack of central control is both it's greatest and most frustrating feature.
Workflows/Branching Strategy. This is by far the most opinionated aspect of Git. Everyone has what they believe is the best workflow, and Git really makes zero effort in being opinionated. I've used Git Flow, Rebasing, Release Merges, and others I'm not entirely sure I understand the name of. I understand they all have their place, but for the love of all that is holy, STANDARDISE as a community and tool ecosystem. Yes, I can get someone out of 3-way conflicting merge, but that doesn't mean I enjoy it. I feel a lot of the Git tooling lends itself to more confusing workflows and bad situations due to lack of opinion on how things should be done.
Checkouts. From what Microsoft says (I believe them, for what it's worth), the Windows codebase is the largest Git repository in the world. Checkouts take HOURS, hurting both developer and build infrastructure. Microsoft had to write a tool called git-vfs, which leverages a virtual filesystem representative of the remote repository, so when a developer checks something out, they are only checking out the files they are working on, not the entire tree. The checkout process shouldn't need to resolve the entire tree, and n-10 should almost be the default to prevent long wait times.
I think Git is a good tool; I don't see it as the end-all, and I definitely think it has a long way to go before it could ever be considered the end-all tool.
git pull upstream master > means pull from upstream whatever my master branch is tracking.
git checkout upstream/master > means checkout the master branch on upstream.
They do different things against different branches, master and upstream/master are two completly different refs. If you can't see this you haven't grasped git yet.
The second command leaves you in a detached head state btw.
Disappointing response to a very thoughtful, well written and accurate critique. Mike Lloyd (original poster) does understand the difference (read it carefully). The point was that the design present an unnecessary and high barrier to entry.
Git is very clever, but there is almost no abstraction between the underlying implementation and the user interface (command line). As another example some commands and combined into aliases (pull is fetch and merge), some commands are combined using a flag (checkout -b is branch and checkout) and changing the case of a flag often changes the behaviour in subtle ways.
I stopping the discussing right here. Git is not a finished product, never indented to have a proper user interface; git is complex until you grasp it, that why you're complaining about git.
I absolutely love git, I my response to your a 'flag is just the same as running 2 commands' and how that is, I don't know, is that confusing? is that the issue? Thats syntactic sugar, makes you type less and do more (usually added to things people use a lot); you can always ignore it.
A yardstick/measurement for good software I have found helpful to apply is:
a. Does it make simple things easy?
b. Does it make complex things possible?
I would not score git highly on the first of these two criteria.
To address these two points specifically, I don't feel they stand up to much critical analysis:
"git is complex until you grasp it
Lots of other software is also complex (in some cases even more complex that git). The issue is not with the complexity the issue is with the level of abstraction (or lack thereof) from the implementation.
flag is just the same as running 2 commands' and how that is
Lots of languages/tools use syntactic sugar (shortcuts/aliases) and are far more consistent in their approach. There is no problem with adding a flag in order to combine two commands if this approach is applied consistently (and with git it is not as per examples cited).
Being passionate about technology is great - but in my experience the best engineers and developers I have worked with also have:
i. The ability to evaluate tools and technology (pros and cons) rationally with as little personal bias as possible.
ii. Empathy, understanding and the ability to listen for others.
Please note I am not picking on you personally or trying to patronise - it is not simple and I am still working on these skill as well.
I do feel this thread would progress much better if you didn't make baseless accusations (examples below):
"I can safely say your first line is copy pasted."
"you haven't grasped git yet."
Thanks for your comment. The point I made was exactly what you explained, they perform two different actions with different results, but the ambiguity of the commands doesn't help new users nor is it explained well.
If you can't see this you haven't grasped git yet.
I don't think there's a need to be rude. If you can't see this then you haven't grasped it yet. ;)
Programming languages enthusiast. Author of Learn Type Driven Development: https://www.packtpub.com/application-development/learn-type-driven-development
Re: (2), this seems to be a different problem than what git is trying to solve. What you're describing sounds like a distributed, peer-to-peer git protocol server. That is a problem vastly different in size and scope than a 'dumb content tracker' that git set out to be. It's a problem that really the GitHubs and the GitLabs of the world should be solving, imho.
Re: (3), people can't even standardize on tabs or spaces in this industry, I think you're asking for too much here 😉
Re: (4), Windows codebase checkouts are one thing, but in most real-world projects, checkouts probably are not going to involve traversing gigabytes of files. Even leaving aside that subsequent checkouts will be faster because git just needs to diff files in place, even the initial checkout should not be a big deal for most projects. Unless you work on Windows, of course.
Re: being considered the end-all tool, you're absolutely right about that, git should not be considered the end-all tool, because it never set out to be that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
When I see git, I see several challenges.
Usability. I've used git for years with libgit2, git2go, various Python libraries, etc. Git is very complicated and there is no easy way to use it programmatically, nor is is the CLI always straight forward.
git pull upstream masterdoesn't have the same syntax asgit checkout upstream/master. There are the standard commands and the porcelain commands, when to use which and which solves the proper problem? These things may be evident to me, but to younger devs? It's black magic with a side of voodoo. I actually got my current job helping someone get unstuck from a git problem (no joke, ask me about it sometime)...No centrality. Git succeeds over Subversion because of it's lack of centrality, but while we've all agreed upon Github as the OSS standard, what happens when Github is unavailable? Granted, this problem exists for Subversion, but I know I'd like to see a multi-master, peered server with consistency to help solve this problem. Granted, this solves one problem and potentially creates others, but availability is important if you communally centralise. In my mind, Git's lack of central control is both it's greatest and most frustrating feature.
Workflows/Branching Strategy. This is by far the most opinionated aspect of Git. Everyone has what they believe is the best workflow, and Git really makes zero effort in being opinionated. I've used Git Flow, Rebasing, Release Merges, and others I'm not entirely sure I understand the name of. I understand they all have their place, but for the love of all that is holy, STANDARDISE as a community and tool ecosystem. Yes, I can get someone out of 3-way conflicting merge, but that doesn't mean I enjoy it. I feel a lot of the Git tooling lends itself to more confusing workflows and bad situations due to lack of opinion on how things should be done.
Checkouts. From what Microsoft says (I believe them, for what it's worth), the Windows codebase is the largest Git repository in the world. Checkouts take HOURS, hurting both developer and build infrastructure. Microsoft had to write a tool called git-vfs, which leverages a virtual filesystem representative of the remote repository, so when a developer checks something out, they are only checking out the files they are working on, not the entire tree. The checkout process shouldn't need to resolve the entire tree, and n-10 should almost be the default to prevent long wait times.
I think Git is a good tool; I don't see it as the end-all, and I definitely think it has a long way to go before it could ever be considered the end-all tool.
Ok, had to step in.
git pull upstream master> means pull from upstream whatever my master branch is tracking.git checkout upstream/master> means checkout the master branch on upstream.They do different things against different branches, master and upstream/master are two completly different refs. If you can't see this you haven't grasped git yet.
The second command leaves you in a detached head state btw.
Disappointing response to a very thoughtful, well written and accurate critique. Mike Lloyd (original poster) does understand the difference (read it carefully). The point was that the design present an unnecessary and high barrier to entry.
Git is very clever, but there is almost no abstraction between the underlying implementation and the user interface (command line). As another example some commands and combined into aliases (pull is fetch and merge), some commands are combined using a flag (checkout -b is branch and checkout) and changing the case of a flag often changes the behaviour in subtle ways.
I can safely say your first line is copy pasted.
I stopping the discussing right here. Git is not a finished product, never indented to have a proper user interface; git is complex until you grasp it, that why you're complaining about git.
I absolutely love git, I my response to your a 'flag is just the same as running 2 commands' and how that is, I don't know, is that confusing? is that the issue? Thats syntactic sugar, makes you type less and do more (usually added to things people use a lot); you can always ignore it.
A yardstick/measurement for good software I have found helpful to apply is:
a. Does it make simple things easy?
b. Does it make complex things possible?
I would not score git highly on the first of these two criteria.
To address these two points specifically, I don't feel they stand up to much critical analysis:
Lots of other software is also complex (in some cases even more complex that git). The issue is not with the complexity the issue is with the level of abstraction (or lack thereof) from the implementation.
Lots of languages/tools use syntactic sugar (shortcuts/aliases) and are far more consistent in their approach. There is no problem with adding a flag in order to combine two commands if this approach is applied consistently (and with git it is not as per examples cited).
Being passionate about technology is great - but in my experience the best engineers and developers I have worked with also have:
i. The ability to evaluate tools and technology (pros and cons) rationally with as little personal bias as possible.
ii. Empathy, understanding and the ability to listen for others.
Please note I am not picking on you personally or trying to patronise - it is not simple and I am still working on these skill as well.
I do feel this thread would progress much better if you didn't make baseless accusations (examples below):
"I can safely say your first line is copy pasted."
"you haven't grasped git yet."
Thanks for your comment. The point I made was exactly what you explained, they perform two different actions with different results, but the ambiguity of the commands doesn't help new users nor is it explained well.
I don't think there's a need to be rude. If you can't see this then you haven't grasped it yet. ;)
Re: (2), this seems to be a different problem than what git is trying to solve. What you're describing sounds like a distributed, peer-to-peer git protocol server. That is a problem vastly different in size and scope than a 'dumb content tracker' that git set out to be. It's a problem that really the GitHubs and the GitLabs of the world should be solving, imho.
Re: (3), people can't even standardize on tabs or spaces in this industry, I think you're asking for too much here 😉
Re: (4), Windows codebase checkouts are one thing, but in most real-world projects, checkouts probably are not going to involve traversing gigabytes of files. Even leaving aside that subsequent checkouts will be faster because git just needs to diff files in place, even the initial checkout should not be a big deal for most projects. Unless you work on Windows, of course.
Re: being considered the end-all tool, you're absolutely right about that, git should not be considered the end-all tool, because it never set out to be that.