3 ms·

> I don't understand any developer's that aren't willing to put in the time to learn how to use Git I can effectively use, I don’t know, probably the about 5%

> I don't understand any developer's that aren't willing to put in the time to learn how to use Git I can effectively use, I don’t know, probably the about 5% of git that I need to do my job. It could maybe benefit me to learn 5% more? The rest feels like a trivia rabbit hole, I have shit to do, and I already have a lot of difficulty with cognitive load and far too many yaks to shave daily. With that said, I have no strong disagreement with you, but I do want to add a bit of nuance: “learn how to use git” is extraordinarily open-ended, and one of the most challenging parts is to know where to even start. Or continued learning has any practical benefit. A little less nuanced: I encourage everyone who will listen, even experienced devs, to use a GUI frontend. Not just because GUIs do ~90% of what you’ll normally need in a daily workflow (which is especially good for noobs who learn which things are important to know first). Also because the GUIs generally have really obvious cues for how to unfuck a mistake, which is the most difficult thing for people who aren’t already well adjusted to git. I use a git GUI for almost all of my version control tasks, and I’m much more effective for it. I’ve learned more how to use the git CLI for an art project than I’ve ever needed to know for normal work processes. (Self nit: bullshit made up approximately educated guess percentages)

js2 4y ago
> “learn how to use git” is extraordinarily open-ended, and one of the most challenging parts is to know where to even start. It's not really. It seems like it is because it has a baroque CLI with a ton of commands and those commands all have a ton of switches and the same commands can do lots of different things. But under that atrocious CLI git is very elegant and simple conceptually. Once you understand the underlying concepts (blobs, trees, commits, refs, index/stage) the rest flows naturally. Now I've been working with it since its earliest days including contributing to it here and there, but I never really found it very hard to grok. "Git from the bottom up" is dated but git hasn't changed conceptually since then. "Git for computer scientists" is another good one. But any of the tutorials that start with git's low-level concepts and build from there are where I'd start.
- eyelidlessness 4y ago
  > It's not really. It seems like it is because it has a baroque CLI with a ton of commands and those commands all have a ton of switches and the same commands can do lots of different things.
  - eyelidlessness 4y ago
    This quote-only reply was meant with kindness, but you made my point far better than I could have made it myself.
    - deleted 4y ago
      [deleted]
    - deleted 4y ago
      [deleted]
    - js2 4y ago
      Do you want to be right or do you want to win? I was trying to remain sympathetic to your concerns while offering an alternate approach to learning git you might not have considered. I don’t have any trouble with git’s CLI but I understand why people find it frustrating. That is all.
      - eyelidlessness 4y ago
        > Do you want to be right or do you want to win? Neither! I appreciate your perspective, and wish I’d emphasized that more than I did.
- vbezhenar 4y ago
  I’ve yet to meet anyone using git command line in their day to day activity. Everyone’s just using IDE. So IMO git CLI is not the issue in most scenarios. You might want to have git guru in your team to resolve some particularly hard situations, but that should be an exceptional situation.
bacon_waffle 4y ago
This (and the reply to js2) gives me the impression that "effectively use 5% of git" means something like "effectively use 5% of the git CLI surface", but to me that's not what "learn how to use git" means. One way or another, I've wound up becoming the git guy at work, and think I'm on the more proficient side of average. But, for most anything outside of commands I use daily (or can easily find in shell history), I'm off to the git docs or a search engine. Just about always, I know what I need git to do, it's just a matter of finding an incantation to do it. To me, there are two pieces to learning git. The lower level is about git itself: understanding that commits are snapshots and the diffs are calculated on-the-fly, that cherry-pick is an automated version of diff and patch, rebase is like a way to compose cherry-picks. The other layer is about how the organisation uses git - like how to fork a project on github, push some changes to a branch in your fork, make a PR to propose those changes to upstream, why committing directly to main is a bad idea.
- Someone 4y ago
  > understanding that commits are snapshots and the diffs are calculated on-the-fly I never understood why that gets mentioned as essential for understanding git. A version control system has to be able to produce both all versions of a given file and diffs between versions of a file, but how it does that is an implementation detail. There are many options there: full first version with diffs to newer versions, full last version with diffs to older versions, variants of those with full versions inserted every now and then, mixes of forward and backward diffs (as is done in some video formats, if you see each frame as a version of a file), etc. Of course, there may be performance reasons for choosing an implementation. I could understand statements such as “Because of the existence of merge commits, it’s easier to store full files, rather than diffs, as a merge commit would have diffs with each of its parent that must be kept consistent”, but the “understanding that commits are snapshots” claim isn’t about implantation details, but claimed to be essential to understand git.
  - nicoburns 4y ago
    I think a key thing that may be trying to be communicated here is that in guy, commits are primitive, and not branches.

js2 4y ago

> “learn how to use git” is extraordinarily open-ended, and one of the most challenging parts is to know where to even start. It's not really. It seems like it is because it has a baroque CLI with a ton of commands and those commands all have a ton of switches and the same commands can do lots of different things. But under that atrocious CLI git is very elegant and simple conceptually. Once you understand the underlying concepts (blobs, trees, commits, refs, index/stage) the rest flows naturally. Now I've been working with it since its earliest days including contributing to it here and there, but I never really found it very hard to grok. "Git from the bottom up" is dated but git hasn't changed conceptually since then. "Git for computer scientists" is another good one. But any of the tutorials that start with git's low-level concepts and build from there are where I'd start.

eyelidlessness 4y ago
> It's not really. It seems like it is because it has a baroque CLI with a ton of commands and those commands all have a ton of switches and the same commands can do lots of different things.
- eyelidlessness 4y ago
  This quote-only reply was meant with kindness, but you made my point far better than I could have made it myself.
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
  - js2 4y ago
    Do you want to be right or do you want to win? I was trying to remain sympathetic to your concerns while offering an alternate approach to learning git you might not have considered. I don’t have any trouble with git’s CLI but I understand why people find it frustrating. That is all.
    - eyelidlessness 4y ago
      > Do you want to be right or do you want to win? Neither! I appreciate your perspective, and wish I’d emphasized that more than I did.
vbezhenar 4y ago
I’ve yet to meet anyone using git command line in their day to day activity. Everyone’s just using IDE. So IMO git CLI is not the issue in most scenarios. You might want to have git guru in your team to resolve some particularly hard situations, but that should be an exceptional situation.

bacon_waffle 4y ago

This (and the reply to js2) gives me the impression that "effectively use 5% of git" means something like "effectively use 5% of the git CLI surface", but to me that's not what "learn how to use git" means. One way or another, I've wound up becoming the git guy at work, and think I'm on the more proficient side of average. But, for most anything outside of commands I use daily (or can easily find in shell history), I'm off to the git docs or a search engine. Just about always, I know what I need git to do, it's just a matter of finding an incantation to do it. To me, there are two pieces to learning git. The lower level is about git itself: understanding that commits are snapshots and the diffs are calculated on-the-fly, that cherry-pick is an automated version of diff and patch, rebase is like a way to compose cherry-picks. The other layer is about how the organisation uses git - like how to fork a project on github, push some changes to a branch in your fork, make a PR to propose those changes to upstream, why committing directly to main is a bad idea.

Someone 4y ago
> understanding that commits are snapshots and the diffs are calculated on-the-fly I never understood why that gets mentioned as essential for understanding git. A version control system has to be able to produce both all versions of a given file and diffs between versions of a file, but how it does that is an implementation detail. There are many options there: full first version with diffs to newer versions, full last version with diffs to older versions, variants of those with full versions inserted every now and then, mixes of forward and backward diffs (as is done in some video formats, if you see each frame as a version of a file), etc. Of course, there may be performance reasons for choosing an implementation. I could understand statements such as “Because of the existence of merge commits, it’s easier to store full files, rather than diffs, as a merge commit would have diffs with each of its parent that must be kept consistent”, but the “understanding that commits are snapshots” claim isn’t about implantation details, but claimed to be essential to understand git.
- nicoburns 4y ago
  I think a key thing that may be trying to be communicated here is that in guy, commits are primitive, and not branches.