4 ms·

I don't really understand struggles with git. I learned ~10 commands 15 years ago which have worked fine for me. I don't think I deeply understand git internals

I don't really understand struggles with git. I learned ~10 commands 15 years ago which have worked fine for me. I don't think I deeply understand git internals but it does what I need so not compelled to dig deeper.

Vaslo 2y ago
This is a point that is not made enough. Git can be overly complicated if you want it to be. But 99% of your work is add, committing, branching and resetting. If you can do that you can probably never need much more. I will say though that I get really nervous reverting sometimes, making sure I’m using the right command to reset etc can be confusing.
- dailykoder 2y ago
  This. Maybe even more than 99% of the time you are fine. It's okay to struggle a day with a rare problem every now and then. Just don't be scared of it. There are enough resources out there to research them when you need them. Where I still get nervous is when I force push my branch after a rebase, even if I know I am the only one working on it. But this is also one of these examples. If I remember correctly, there are other options to sync your remote after you did a rebase, but force push is just the easiest. So I rather take 5 seconds to make sure I typed exactly what I wanted and that everything is fine and that just works. Edit: I was just brainstorming a bit about it and thought that probably some of the unknown magic git features were just implemented by a motivated dev that just wanted to explore what's possible. But on the other hand, there are most likely some very very obscure configurations and edge cases in the wild where people actually need those features. But most people will likely never need them, so I myself won't bother understanding "everything"
  - osigurdson 2y ago
    Agree. It only makes sense to be scared of it if direct pushes to master are allowed - that would be crazy. This + avoid long running branches and there isn't much to fear.
    - dylan604 2y ago
      [flagged]
  - milesrout 2y ago
    >Where I still get nervous is when I force push my branch after a rebase, even if I know I am the only one working on it. It sounds like you recognise that this is an irrational fear but in case you don't: this is an irrational fear.
    - rectang 2y ago
      I agree that it won't cause collaboration issues. Perhaps the fear arises because force pushing destroys your backup, so to speak? I freed myself from the fear of losing data after a rebase when I learned to restore from a commit in `git reflog`. So long as your work made it into an actual commit at some point, everything is recoverable from the local repo's history[1]. [1] Ignoring giganto repos that actually trigger garbage collection.
      - fragmede 2y ago
        you could do git checkout -b backup-of-branch-foo and push that, before force pushing branch-foo, for the paranoid
sweezyjeezy 2y ago
I actually think git is a bad example of "just memorise these commands" - unless you are working with projects with a small number of users / branches - or you're fine to just delete and reclone if things get really hairy. I think a lot of my struggles with git came down to not grokking what it was actually DOING at first. Examples: - not understanding branch pointers / staging / committing corrently. E.g. [add file] [modify file again] [commit] - what just happened? (IMO these things could have been named better). Also reset vs revert vs restore - easier to use these if you've internalised branch pointers etc - git pull fails because it says it would overwrite a file you've never heard of - how is that file on your local? Is it ok to delete it? - times when you (or your colleagues) need to rewrite history (rebase / squashing etc) - require a pretty good mental model of what is going on to both diagnose issues and to fix them
- suzzer99 2y ago
  If you work at a place that doesn't care about a curated history, which I always have, it becomes much simpler.
  - ninetyninenine 2y ago
    It’s more accurate too. Linear rebased histories aren’t representative of what occurred. I think much of the confusion comes from git log which is a lie. People want git log to be an accurate representation of what occurred.
    - echelon 2y ago
      Single squashed commits with a linear history. This scales for monorepos with thousands of engineers, too.
    - convolvatron 2y ago
      I've worked in more than one place where a 'clean history' was deemed so valuable that someone and re-applied all the deltas after the fact to create some kind of alternative timeline where everything landed just so, and we all had to eat the resulting force pushes to main
yodsanklai 2y ago
It's hard not to get stuck at some point if you don't have some understanding of the internals. If I was a beginner, I'll try to get some proficiency early on rather than having to learn the hard way when you're on the middle of a project. It's a good investment. I've also found that learning crafting nice commits made me a better programmer. It seemed difficult at first but now it's second nature (and I assume that in most teams, one is expected to submit small and self-contained commits anyway).
- osigurdson 2y ago
  That is my main point, I have never gotten stuck despite not deeply understanding the internals. Instead I built a solid mental model just from the behavior of the commands.
- anonzzzies 2y ago
  Never gotten stuck in the more than 15 years (cvs etc before it) of using it; never needed a gui and hardly needed to look up anything (but we can do what's the issue with that?); work(ed) on massive projects. It's just not that hard.
getnormality 2y ago
This is like saying "I've lived in a house for 15 years and I've never had a problem. I don't understand how people could have a problem living in a house." The thing is, living in a house isn't a very specific experience. The difficulty of the problems you might face varies a lot by many factors.
- osigurdson 2y ago
  If I run into a problem I would research it, what is so bad about that? Even if I studied git source code in detail 15 years ago I would have forgotten it by now. Do you know how to build a working computer from individual transistors or understand the physics behind it (I happen to know these things personally)? If not, better crack open your modern physics text and study particle in a box, along with the requisite differential equations, calculous and linear algebra just in case you might run into a problem one day.
m3kw9 2y ago
Git init is all I need. The rest is just from gui
commandlinefan 2y ago
> I learned ~10 commands 15 years ago Same here - I've been using it for a long time without any real deep understanding of it and still no issues. I _do_ believe that there's a "hidden" layer of collaborative functionality that I'm missing out on, but since everybody I work with uses git the same way I do, I suspect that if I did know what I was missing out on, I'd just be frustrated that I wasn't able to take advantage of it.
- fragmede 2y ago
  Git bisect is the functionality that you're missing out on.
  - commandlinefan 2y ago
    rebase, too, probably, I've never done one of those, but I hear they're popular.

Vaslo 2y ago

This is a point that is not made enough. Git can be overly complicated if you want it to be. But 99% of your work is add, committing, branching and resetting. If you can do that you can probably never need much more. I will say though that I get really nervous reverting sometimes, making sure I’m using the right command to reset etc can be confusing.

dailykoder 2y ago
This. Maybe even more than 99% of the time you are fine. It's okay to struggle a day with a rare problem every now and then. Just don't be scared of it. There are enough resources out there to research them when you need them. Where I still get nervous is when I force push my branch after a rebase, even if I know I am the only one working on it. But this is also one of these examples. If I remember correctly, there are other options to sync your remote after you did a rebase, but force push is just the easiest. So I rather take 5 seconds to make sure I typed exactly what I wanted and that everything is fine and that just works. Edit: I was just brainstorming a bit about it and thought that probably some of the unknown magic git features were just implemented by a motivated dev that just wanted to explore what's possible. But on the other hand, there are most likely some very very obscure configurations and edge cases in the wild where people actually need those features. But most people will likely never need them, so I myself won't bother understanding "everything"
- osigurdson 2y ago
  Agree. It only makes sense to be scared of it if direct pushes to master are allowed - that would be crazy. This + avoid long running branches and there isn't much to fear.
  - dylan604 2y ago
    [flagged]
- milesrout 2y ago
  >Where I still get nervous is when I force push my branch after a rebase, even if I know I am the only one working on it. It sounds like you recognise that this is an irrational fear but in case you don't: this is an irrational fear.
  - rectang 2y ago
    I agree that it won't cause collaboration issues. Perhaps the fear arises because force pushing destroys your backup, so to speak? I freed myself from the fear of losing data after a rebase when I learned to restore from a commit in `git reflog`. So long as your work made it into an actual commit at some point, everything is recoverable from the local repo's history[1]. [1] Ignoring giganto repos that actually trigger garbage collection.
    - fragmede 2y ago
      you could do git checkout -b backup-of-branch-foo and push that, before force pushing branch-foo, for the paranoid

sweezyjeezy 2y ago

I actually think git is a bad example of "just memorise these commands" - unless you are working with projects with a small number of users / branches - or you're fine to just delete and reclone if things get really hairy. I think a lot of my struggles with git came down to not grokking what it was actually DOING at first. Examples: - not understanding branch pointers / staging / committing corrently. E.g. [add file] [modify file again] [commit] - what just happened? (IMO these things could have been named better). Also reset vs revert vs restore - easier to use these if you've internalised branch pointers etc - git pull fails because it says it would overwrite a file you've never heard of - how is that file on your local? Is it ok to delete it? - times when you (or your colleagues) need to rewrite history (rebase / squashing etc) - require a pretty good mental model of what is going on to both diagnose issues and to fix them

suzzer99 2y ago
If you work at a place that doesn't care about a curated history, which I always have, it becomes much simpler.
- ninetyninenine 2y ago
  It’s more accurate too. Linear rebased histories aren’t representative of what occurred. I think much of the confusion comes from git log which is a lie. People want git log to be an accurate representation of what occurred.
  - echelon 2y ago
    Single squashed commits with a linear history. This scales for monorepos with thousands of engineers, too.
  - convolvatron 2y ago
    I've worked in more than one place where a 'clean history' was deemed so valuable that someone and re-applied all the deltas after the fact to create some kind of alternative timeline where everything landed just so, and we all had to eat the resulting force pushes to main

yodsanklai 2y ago

It's hard not to get stuck at some point if you don't have some understanding of the internals. If I was a beginner, I'll try to get some proficiency early on rather than having to learn the hard way when you're on the middle of a project. It's a good investment. I've also found that learning crafting nice commits made me a better programmer. It seemed difficult at first but now it's second nature (and I assume that in most teams, one is expected to submit small and self-contained commits anyway).

osigurdson 2y ago
That is my main point, I have never gotten stuck despite not deeply understanding the internals. Instead I built a solid mental model just from the behavior of the commands.
anonzzzies 2y ago
Never gotten stuck in the more than 15 years (cvs etc before it) of using it; never needed a gui and hardly needed to look up anything (but we can do what's the issue with that?); work(ed) on massive projects. It's just not that hard.

getnormality 2y ago

This is like saying "I've lived in a house for 15 years and I've never had a problem. I don't understand how people could have a problem living in a house." The thing is, living in a house isn't a very specific experience. The difficulty of the problems you might face varies a lot by many factors.

osigurdson 2y ago
If I run into a problem I would research it, what is so bad about that? Even if I studied git source code in detail 15 years ago I would have forgotten it by now. Do you know how to build a working computer from individual transistors or understand the physics behind it (I happen to know these things personally)? If not, better crack open your modern physics text and study particle in a box, along with the requisite differential equations, calculous and linear algebra just in case you might run into a problem one day.

m3kw9 2y ago

Git init is all I need. The rest is just from gui

commandlinefan 2y ago

> I learned ~10 commands 15 years ago Same here - I've been using it for a long time without any real deep understanding of it and still no issues. I _do_ believe that there's a "hidden" layer of collaborative functionality that I'm missing out on, but since everybody I work with uses git the same way I do, I suspect that if I did know what I was missing out on, I'd just be frustrated that I wasn't able to take advantage of it.

fragmede 2y ago
Git bisect is the functionality that you're missing out on.
- commandlinefan 2y ago
  rebase, too, probably, I've never done one of those, but I hear they're popular.