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