4 ms·

That's nice but I prefer people to use the "real" git just so they know how it works and can manage when inevitably something goes wrong.

SOLAR_FIELDS 7y ago
I agree to an extent. The main reason I prefer the “bare” command line tools instead of sugary wrappers like this is for situations when I’m stuck in a fire and don’t have my normal tools available to me. Examples include when you need to do work on someone else’s machine or more commonly when you are ssh’ed into some cloud infrastructure and you don’t have anything but the basic tools available to work (and no permissions to install stuff like this from outside the firewall). This philosophy applies more to knowing your way around bash but also can apply to git as well. It’s probably as not as big of a deal for people who never venture into ops land but if you’ve ever done any sort of ops related work you know that sometimes you’re only given hammers and screwdrivers instead of power tools and expected to make it work. That said I do see the value in these tools - git is quite an intimidating beast and any tools that help people become more familiar with it can’t be a bad thing - so long as they don’t eventually become a crutch for the end user to avoid learning about how the base tool works.
- pearjuice 7y ago
  How is git intimidating? It's one of the most user friendly pieces of CLI applications out there, offers a myriad of ways to "ctrl z" and has proper documentation. Problem is people don't get trained or don't want to learn. They learn "git pull" and "git commit" and then think they know how it works.
  - EForEndeavour 7y ago
    I honestly can't tell if you're serious. Some things off the top of my head that are in my opinion not at all trivial for even intermediate git users: - How do you fix a typo in the commit message of the second-last commit that you pushed to remote? - I accidentally committed something to the wrong branch. What's the best way to uncommit it from that branch and commit it to the right branch? - What are the differences between the working tree, directory tree, index, and staging area? - How do I "un-add" a file I just staged? - I've heard "git reflog" is useful. What is it?
    - pearjuice 7y ago
      If you have had any interaction beyond the basics of git those are trivial to solve. - git rebase -i HEAD~2 -- interactive rebase of last 2 commits then read the help you get (use reword on the commit you want to change, needs force push because rewriting history) - various ways to do this but easiest is: checkout correct branch, cherry-pick commit you want and then hard reset your faulty branch HEAD~1 (you can also soft reset, keep it staging and then checkout correct branch and commit) - these are all terms you should know if you are using git in my opinion because the commands et cetera will assume you know what they mean. I think it comes with every beginners git tutorial? - I am pretty sure git status will tell you how to do this by default (which shows staging area) - this is also properly documented and something a good git guide will gloss over Maybe I am biased because I use git on a daily basis but I don't think any of these are hard. Anyone who calls themselves an intermediate git user should be able to answer these questions from the top of their head. If you don't, no problem, you can easily Google them and you will notice that they are very straightforward and simple. I am not even sarcastic, git is very simple software (in terms of usage and help/documentation available).

SOLAR_FIELDS 7y ago

I agree to an extent. The main reason I prefer the “bare” command line tools instead of sugary wrappers like this is for situations when I’m stuck in a fire and don’t have my normal tools available to me. Examples include when you need to do work on someone else’s machine or more commonly when you are ssh’ed into some cloud infrastructure and you don’t have anything but the basic tools available to work (and no permissions to install stuff like this from outside the firewall). This philosophy applies more to knowing your way around bash but also can apply to git as well. It’s probably as not as big of a deal for people who never venture into ops land but if you’ve ever done any sort of ops related work you know that sometimes you’re only given hammers and screwdrivers instead of power tools and expected to make it work. That said I do see the value in these tools - git is quite an intimidating beast and any tools that help people become more familiar with it can’t be a bad thing - so long as they don’t eventually become a crutch for the end user to avoid learning about how the base tool works.

pearjuice 7y ago
How is git intimidating? It's one of the most user friendly pieces of CLI applications out there, offers a myriad of ways to "ctrl z" and has proper documentation. Problem is people don't get trained or don't want to learn. They learn "git pull" and "git commit" and then think they know how it works.
- EForEndeavour 7y ago
  I honestly can't tell if you're serious. Some things off the top of my head that are in my opinion not at all trivial for even intermediate git users: - How do you fix a typo in the commit message of the second-last commit that you pushed to remote? - I accidentally committed something to the wrong branch. What's the best way to uncommit it from that branch and commit it to the right branch? - What are the differences between the working tree, directory tree, index, and staging area? - How do I "un-add" a file I just staged? - I've heard "git reflog" is useful. What is it?
  - pearjuice 7y ago
    If you have had any interaction beyond the basics of git those are trivial to solve. - git rebase -i HEAD~2 -- interactive rebase of last 2 commits then read the help you get (use reword on the commit you want to change, needs force push because rewriting history) - various ways to do this but easiest is: checkout correct branch, cherry-pick commit you want and then hard reset your faulty branch HEAD~1 (you can also soft reset, keep it staging and then checkout correct branch and commit) - these are all terms you should know if you are using git in my opinion because the commands et cetera will assume you know what they mean. I think it comes with every beginners git tutorial? - I am pretty sure git status will tell you how to do this by default (which shows staging area) - this is also properly documented and something a good git guide will gloss over Maybe I am biased because I use git on a daily basis but I don't think any of these are hard. Anyone who calls themselves an intermediate git user should be able to answer these questions from the top of their head. If you don't, no problem, you can easily Google them and you will notice that they are very straightforward and simple. I am not even sarcastic, git is very simple software (in terms of usage and help/documentation available).