4 ms·

One consolation with Git, you know it is almost always possible to recover from any mistake. Theoretically anyway. I think we've all been in that situation wher

One consolation with Git, you know it is almost always possible to recover from any mistake. Theoretically anyway. I think we've all been in that situation where a team of engineers are huddling round a monitor strategizing about just how to undo the snafu of the day, brainstorming increasingly extreme solutions.

rtkwe 8y ago
Every time I start to dig super deep on problems like this I stop for a second and wonder "just how important is it I fix this error" and "can this be solved by just paving over my local and reapplying my changes...". Most of the time the answer is not extremely and yes.
- plorkyeran 8y ago
  It's true that for any given problem, learning how to fix it probably isn't worth the time. I've found the long-term benefits of taking the time to learn how to fix every problem I've run into (and importantly, understand what the things I'm doing to fix it do) to be very worth it, though. Over time I've had to google how to do fewer and fewer things, and when I do still need to google something it takes me much less time to understand the answer and how to apply it. As a polygot developer working in multiple languages, editors and ecosystems, git has been the one tool that I'm always using, and that makes it always worth investing more time into learning how to use it better.
- krinchan 8y ago
  Same really. I'm considered a "git expert" at work and the extent of my expertise is: "This merge went completely sideways. But I haven't pushed anything." "Okay, do this to export the commits you made as a patch file. Move those somewhere safe. Delete your repo. Reclone. Apply the patches. Commit. Start merge over again." Also I can recognize whatever that weird error message is that means someone deleted a file in one branch and I edited it in another. Usually results in just "git rm (file); and git merge --continue".
  - majewsky 8y ago
    > This merge went completely sideways. git merge --abort
mikro2nd 8y ago
You're probably right. I, though, know just enough GIT to get by. In every case where things have gone seriously pear-shaped, it's just quicker -- like days quicker -- for me just to throw everything to the wind and clone the repo again. Reading up how to do the proper thing a recover will just take me order-of-magnitude longer, and frankly, I don't have the time. Just think how many person-hours were wasted by that team huddled around the monitor... GIT: The Swiss-Army Chainsaw of Version Management.
- habitue 8y ago
  Once you understand a few basic things like the underlying git model, and what the reflog is, you can basically get out of any situation. Totally worth the time to learn, it'll save you a ton of time
  - bhj 8y ago
    The interface should be what saves a ton of time, and should not expose the underlying technical model (especially because that model may change at some point)
    - habitue 8y ago
      I don't think it's reasonable at this point that git's underlying model ever changes substantially. Essentially, it is the interface that's stable over time. It's also the easiest way to understand git. You could learn to read by memorizing the shapes of thousands of words without learning the alphabet or how it matches up to sounds. I'm sure people have done it. But the failure mode when encountering a new word is complete and utter bewilderment that this new shape is unfamiliar, rather than a graceful degradation you get if you understand the alphabet. The same is true of git.
      - zaphar 8y ago
        This is funny because the lack of consistency in Git's user interface forces you into memorizing the shapes of specific words (commands and arguments). To spell it's language. The UI does a remarkably good job of hiding the elegant underpinnings from you.

rtkwe 8y ago

Every time I start to dig super deep on problems like this I stop for a second and wonder "just how important is it I fix this error" and "can this be solved by just paving over my local and reapplying my changes...". Most of the time the answer is not extremely and yes.

plorkyeran 8y ago
It's true that for any given problem, learning how to fix it probably isn't worth the time. I've found the long-term benefits of taking the time to learn how to fix every problem I've run into (and importantly, understand what the things I'm doing to fix it do) to be very worth it, though. Over time I've had to google how to do fewer and fewer things, and when I do still need to google something it takes me much less time to understand the answer and how to apply it. As a polygot developer working in multiple languages, editors and ecosystems, git has been the one tool that I'm always using, and that makes it always worth investing more time into learning how to use it better.
krinchan 8y ago
Same really. I'm considered a "git expert" at work and the extent of my expertise is: "This merge went completely sideways. But I haven't pushed anything." "Okay, do this to export the commits you made as a patch file. Move those somewhere safe. Delete your repo. Reclone. Apply the patches. Commit. Start merge over again." Also I can recognize whatever that weird error message is that means someone deleted a file in one branch and I edited it in another. Usually results in just "git rm (file); and git merge --continue".
- majewsky 8y ago
  > This merge went completely sideways. git merge --abort

mikro2nd 8y ago

You're probably right. I, though, know just enough GIT to get by. In every case where things have gone seriously pear-shaped, it's just quicker -- like days quicker -- for me just to throw everything to the wind and clone the repo again. Reading up how to do the proper thing a recover will just take me order-of-magnitude longer, and frankly, I don't have the time. Just think how many person-hours were wasted by that team huddled around the monitor... GIT: The Swiss-Army Chainsaw of Version Management.

habitue 8y ago
Once you understand a few basic things like the underlying git model, and what the reflog is, you can basically get out of any situation. Totally worth the time to learn, it'll save you a ton of time
- bhj 8y ago
  The interface should be what saves a ton of time, and should not expose the underlying technical model (especially because that model may change at some point)
  - habitue 8y ago
    I don't think it's reasonable at this point that git's underlying model ever changes substantially. Essentially, it is the interface that's stable over time. It's also the easiest way to understand git. You could learn to read by memorizing the shapes of thousands of words without learning the alphabet or how it matches up to sounds. I'm sure people have done it. But the failure mode when encountering a new word is complete and utter bewilderment that this new shape is unfamiliar, rather than a graceful degradation you get if you understand the alphabet. The same is true of git.
    - zaphar 8y ago
      This is funny because the lack of consistency in Git's user interface forces you into memorizing the shapes of specific words (commands and arguments). To spell it's language. The UI does a remarkably good job of hiding the elegant underpinnings from you.