20 ms·

I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cov

I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when you've just started using it. That's where GUI tools come useful, as people are generally less scared of GUI tools - they make you feel there's less of chance of making a mistake because you put the trust in the tool to stop them doing something obviously stupid. However IME that trust is not really deserved as most of the GUI tools will just as happily let you mess up your repository...

mumblemumble 6y ago
I suspect that the underlying model wouldn't be so scary, either, if the UI had not done such a stellar job of obfuscating it.
wpietri 6y ago
I think more than one thing can be a problem. The CLI is confusing and the model is complicated. This means people can get themselves into weird, hard-to-debug situations. Or end up copy-pasting incantations in hopes of fixing problems, but instead might lose their work.
- RichardCA 6y ago
  I've never seen a scenario that resulted in a developer losing work. You can always retrieve things out of the commit history, even in pathological situations.
  - wpietri 6y ago
    I have lost work. A colleague force-pushed something because he thought he understood Git well enough to get away with it.
    - RichardCA 6y ago
      If you can find your prior branch head with git reflog, you can assign a new branch name to it and push it. Then go back to your force-pushing colleague and tell him to resolve the merge conflict he created by thinking he was too clever.
      - RichardCA 6y ago
        The command "git log --all --oneline --graph --reflog" will give you an exhaustive listing of the commit graph in your local repo. Examine the output of that command in detail before declaring your work to be lost.
simiones 6y ago
You forgot log, cherry, stash, blame, which are also daily use commands. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches, when it is safe to push -F, etc. Depending on the project you joined, you may also have to immediately learn about git LFS, submodules, squashing, fast-forwards, tags. You have to understand a lot of things before you can somewhat comfortably use git, much more than something like P4.
- ritchiea 6y ago
  I think of log, cherry-pick, stash & blame "quarterly use" commands rather than "daily use" commands. log maybe monthly, the rest quarterly unless you're doing something wrong.
  - simiones 6y ago
    How can you pull without using stash? Do you always commit everything before pulling? You also need the log daily to know things like "what changes made it into this build", or almost everytime I fix a merge conflict, to understand why something is the way it is. I can grant that cherry-pick & blame are more rarely used, though blame is often on by default in many editors, and cherry-pick is something my team does daily around every release (since we don't want to merge the trunk into the release branch the day of the release for 1 bugfix).
    - lionkor 6y ago
      `git pull --rebase` ?
      - deleted 6y ago
        [deleted]
      - simiones 6y ago
        If you have a dirty worktree, `git pull --rebase` fails. You need to either commit or stash your local changes. To stash them, you can use git stash. If you decide to commit them, that's ok, but then you also need to learn about `git reset --hard` or `git commit --amend` or `git push --squash` if the changes were work-in-progress. So which would you recommend? Oh, there is also the option of enabling autostash I think, but that is relatively recent (maybe 1 year?)
deleted 6y ago
[deleted]
linuxftw 6y ago
Never use pull, always use fetch. You shouldn't merge changes into your remote tracking branch, it causes nothing but problems.
- samwestdev 6y ago
  Explain
- simiones 6y ago
  You need to use either merge or rebase, or git won't allow you to push. Also, pull doesn't modify your remote tracking branch (origin/branch) - fetch does that. I do agree that usually, when you have a local branch dedicated to a particular remote tracking branch, it's not a good idea to merge the remote into your local branch - it's generally much better to rebase your local branch onto the remote tracking branch (pull -r).
- Seb-C 6y ago
  I was going to negatively answer your comment until I remembered that I have had [pull]rebase=true in my config for almost 10 years, so it have always been the "normal behaviour" to me. I never looked back to this. So I agree with you, the default pull behaviour that pollutes the branch with useless merge commits is plain stupid.
rob74 6y ago
The problem is not the 99% of situations that you can memorize, but the 1% of times when you realize you have made a mistake and strayed from your beaten path into the dark scary unknown Git woods where monsters with detached HEADs may be lurking behind every tree, and you have to ask a coworker or StackOverflow to rescue you...
- emidln 6y ago
  > and you have to ask a coworker or StackOverflow to rescue you... That or you could RTFM. That's what your coworker and the person writing on StackOverflow did.
  - g8oz 6y ago
    Many have and still don't feel comfortable with their understanding. And there's too many of them for inadequacy or incompetence to be a useful explanation.
  - briffle 6y ago
    I have read the manual many times. But when I only run into an issue once every 6 months to a year or so, its not exactly fresh on the mind. I still like to look it up again, to make sure I'm not working wrong from memory, and about to lose my work.
    - emidln 6y ago
      So you agree that you should Read The Fine Manual when you hit unfamiliar territory? My post wasn't aimed at saying git isn't complicated, but to encourage reading the thorough documentation of the tool giving you trouble rather than immediately shutting off the brain in the face of unfamiliarity.
  - Bjartr 6y ago
    Reading TFM and understanding TFM are not the same thing. The more intuitive the design of the system, the closer they are. The point people are trying to make here is that git specifically has an uncomfortably large gap between the two. While people could put in more effort to learn git more thoroughly, there is validity to the sentiment that git could be easier to learn.
AgloeDreams 6y ago
Part of it is feedback to me. The timeline view in most Git Apps makes it super clear to see where you are and where you can go. Starting out in Git with an established repo is like driving at night without headlights.
tasuki 6y ago
> the complexity of the model Git might not be easy, but it's not complex, it's simple. There are basically only four concepts: blobs, trees, commits, and refs. Which systems (not just version control - systems in general) are simpler?
- tharne 6y ago
  This 100%. Git is simple, but not easy. I suspect this is by design. I vastly prefer simple tools over easy ones. Sure, you pay a little more up front in time and initial frustration, but ultimately you really grok the tools and life becomes easier. Often, simplicity comes at the cost of being less user friendly. It's harder to learn to drive a stick shift than an automatic, but the manual transmission is a simpler system than an automatic.
AlchemistCamp 6y ago
It says a lot about your temperament that status, log and reset didn't make your list! I use the first two so much that I've dedicated a keyboard macro key to each.
mryalamanchi 6y ago
Even though naming the commands might be arbitrary choices, they can be practiced upon. One doesn't always have to fall in the semantic trap. The main problem that I see with using git is that when you are part of a team, what kind of release and branching strategy should you use. It's comparatively easy with one person team but becomes complicated with a team and even more if it's an open source project and now you have individual devs contributing their changes.

mumblemumble 6y ago

I suspect that the underlying model wouldn't be so scary, either, if the UI had not done such a stellar job of obfuscating it.

wpietri 6y ago

I think more than one thing can be a problem. The CLI is confusing and the model is complicated. This means people can get themselves into weird, hard-to-debug situations. Or end up copy-pasting incantations in hopes of fixing problems, but instead might lose their work.

RichardCA 6y ago
I've never seen a scenario that resulted in a developer losing work. You can always retrieve things out of the commit history, even in pathological situations.
- wpietri 6y ago
  I have lost work. A colleague force-pushed something because he thought he understood Git well enough to get away with it.
  - RichardCA 6y ago
    If you can find your prior branch head with git reflog, you can assign a new branch name to it and push it. Then go back to your force-pushing colleague and tell him to resolve the merge conflict he created by thinking he was too clever.
    - RichardCA 6y ago
      The command "git log --all --oneline --graph --reflog" will give you an exhaustive listing of the commit graph in your local repo. Examine the output of that command in detail before declaring your work to be lost.

simiones 6y ago

You forgot log, cherry, stash, blame, which are also daily use commands. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches, when it is safe to push -F, etc. Depending on the project you joined, you may also have to immediately learn about git LFS, submodules, squashing, fast-forwards, tags. You have to understand a lot of things before you can somewhat comfortably use git, much more than something like P4.

ritchiea 6y ago
I think of log, cherry-pick, stash & blame "quarterly use" commands rather than "daily use" commands. log maybe monthly, the rest quarterly unless you're doing something wrong.
- simiones 6y ago
  How can you pull without using stash? Do you always commit everything before pulling? You also need the log daily to know things like "what changes made it into this build", or almost everytime I fix a merge conflict, to understand why something is the way it is. I can grant that cherry-pick & blame are more rarely used, though blame is often on by default in many editors, and cherry-pick is something my team does daily around every release (since we don't want to merge the trunk into the release branch the day of the release for 1 bugfix).
  - lionkor 6y ago
    `git pull --rebase` ?
    - deleted 6y ago
      [deleted]
    - simiones 6y ago
      If you have a dirty worktree, `git pull --rebase` fails. You need to either commit or stash your local changes. To stash them, you can use git stash. If you decide to commit them, that's ok, but then you also need to learn about `git reset --hard` or `git commit --amend` or `git push --squash` if the changes were work-in-progress. So which would you recommend? Oh, there is also the option of enabling autostash I think, but that is relatively recent (maybe 1 year?)

deleted 6y ago

[deleted]

linuxftw 6y ago

Never use pull, always use fetch. You shouldn't merge changes into your remote tracking branch, it causes nothing but problems.

samwestdev 6y ago
Explain
simiones 6y ago
You need to use either merge or rebase, or git won't allow you to push. Also, pull doesn't modify your remote tracking branch (origin/branch) - fetch does that. I do agree that usually, when you have a local branch dedicated to a particular remote tracking branch, it's not a good idea to merge the remote into your local branch - it's generally much better to rebase your local branch onto the remote tracking branch (pull -r).
Seb-C 6y ago
I was going to negatively answer your comment until I remembered that I have had [pull]rebase=true in my config for almost 10 years, so it have always been the "normal behaviour" to me. I never looked back to this. So I agree with you, the default pull behaviour that pollutes the branch with useless merge commits is plain stupid.

rob74 6y ago

The problem is not the 99% of situations that you can memorize, but the 1% of times when you realize you have made a mistake and strayed from your beaten path into the dark scary unknown Git woods where monsters with detached HEADs may be lurking behind every tree, and you have to ask a coworker or StackOverflow to rescue you...

emidln 6y ago
> and you have to ask a coworker or StackOverflow to rescue you... That or you could RTFM. That's what your coworker and the person writing on StackOverflow did.
- g8oz 6y ago
  Many have and still don't feel comfortable with their understanding. And there's too many of them for inadequacy or incompetence to be a useful explanation.
- briffle 6y ago
  I have read the manual many times. But when I only run into an issue once every 6 months to a year or so, its not exactly fresh on the mind. I still like to look it up again, to make sure I'm not working wrong from memory, and about to lose my work.
  - emidln 6y ago
    So you agree that you should Read The Fine Manual when you hit unfamiliar territory? My post wasn't aimed at saying git isn't complicated, but to encourage reading the thorough documentation of the tool giving you trouble rather than immediately shutting off the brain in the face of unfamiliarity.
- Bjartr 6y ago
  Reading TFM and understanding TFM are not the same thing. The more intuitive the design of the system, the closer they are. The point people are trying to make here is that git specifically has an uncomfortably large gap between the two. While people could put in more effort to learn git more thoroughly, there is validity to the sentiment that git could be easier to learn.

AgloeDreams 6y ago

Part of it is feedback to me. The timeline view in most Git Apps makes it super clear to see where you are and where you can go. Starting out in Git with an established repo is like driving at night without headlights.

tasuki 6y ago

> the complexity of the model Git might not be easy, but it's not complex, it's simple. There are basically only four concepts: blobs, trees, commits, and refs. Which systems (not just version control - systems in general) are simpler?

tharne 6y ago
This 100%. Git is simple, but not easy. I suspect this is by design. I vastly prefer simple tools over easy ones. Sure, you pay a little more up front in time and initial frustration, but ultimately you really grok the tools and life becomes easier. Often, simplicity comes at the cost of being less user friendly. It's harder to learn to drive a stick shift than an automatic, but the manual transmission is a simpler system than an automatic.

AlchemistCamp 6y ago

It says a lot about your temperament that status, log and reset didn't make your list! I use the first two so much that I've dedicated a keyboard macro key to each.

mryalamanchi 6y ago

Even though naming the commands might be arbitrary choices, they can be practiced upon. One doesn't always have to fall in the semantic trap. The main problem that I see with using git is that when you are part of a team, what kind of release and branching strategy should you use. It's comparatively easy with one person team but becomes complicated with a team and even more if it's an open source project and now you have individual devs contributing their changes.