13 ms·

It never ceases to amaze me that: 1. Git, a software product with more footguns per square inch of user-exposed surface than any I've ever encountered, ended u

It never ceases to amaze me that: 1. Git, a software product with more footguns per square inch of user-exposed surface than any I've ever encountered, ended up winning the distributed VCS sweepstakes; and 2. Even now, more than five years after it was clear to everyone that Git had won, there is absolutely no momentum to go back and clean it up to remove any of those footguns. All we get instead are increasingly shiny GUIs to hide them under, and well-meaning blog posts advising you on which is the best kind of tourniquet to apply when you trigger one of the aforementioned footguns. Sigh.

feintruled 8y ago
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.
marcodave 8y ago
But one of those shiny GUI was called GitHub, and it was the shiniest of the shiniest, so much that it make git usage ridiculously easy. At least on my experience.
- smacktoward 8y ago
  Git is very easy to use, right up to the moment when it really really is not.
  - mikestew 8y ago
    Every SCM/SCC/VCS has a wall you'll hit eventually. Whoopsie, the merge went wrong. Whoopsie, didn't mean to check that in. Whoopsie,... Most version control systems will allow you to crash through that wall with a little damage, might slow you down a little, but you'll keep going. git's wall is thick, made of brick and reinforced concrete, and you'll be heading toward it at 200kph. You'll get going again eventually, once the metaphoric car gets glued back together. Non-metaphorically, my experience has been that with SVN, Mercurial, et. al., a few quick web searches and I'm on my way. With git, "wait a minute...run that by me again?" I've used git for going on a decade, and now that I'm in an SVN shop I do sorely miss it. But, man, it's got some sharp edges.
    - smacktoward 8y ago
      This is a good metaphorical version of what it's like introducing new people to Git: https://www.youtube.com/watch?v=92wPOsuHZ9Y https://www.youtube.com/watch?v=92wPOsuHZ9Y
    - kevin_thibedeau 8y ago
      I've never had to manually edit merge history in Git like SVN forces when merging complicated branch hierarchies. SVN is basically a half implemented VCS where the guts are exposed and you tread lightly whenever doing anything the original design didn't anticipate like ubiquitous merging.
- saagarjha 8y ago
chrisseaton 8y ago
What 'footguns' are there? I find it pleasingly hard to accidentally delete anything, or get myself into any kind of corner when using Git. What am I missing?
- lixtra 8y ago
  Explain detached head like i’m 5 years old.
  - XCabbage 8y ago
    Why should he have to? It's irrelevant to the point he's making, since a tool being conceptually difficult is not the same thing as it having footguns.
    - masklinn 8y ago
      > a tool being conceptually difficult is not the same thing as it having footguns. But the tool is not conceptually difficult. All the difficulty of git is in the trap its "UI" creates for no reason. The concepts are easy. I taught Darcs to a frontend/flash developer 15 years ago, and it's not because I'm a great teacher.
  - xyzzy_plugh 8y ago
    Detached HEAD isn't complicated. It simply means there is nothing tracking the current line of work beyond the commit shas themselves. No branch is updated when you make commits. Conversely, attached HEAD means a branch is being updated whenever you make a commit, e.g. when you make commits on your local master.
    - iainmerrick 8y ago
      But why would I get into that state, and how do I get out without losing my work? Neither of those is obvious.
      - 8y ago
pjmlp 8y ago
Because Linux, basically.
finnthehuman 8y ago
It’s basically a manifestation of programmer arrogance that they’re just too damn smart to encounter a software learning curve again. Ever sat through user training on microsoft office? How to use email? The weird one-off enterprise apps that nobody else has ever heard of? They’re unbearably tedious to users that can get by in a new tool with a 5 minute crash course, intuition and light googling. Then git shows up and has the audacity to ask professionals to learn its mental model. Once you do the interface isn’t great, but not particularly esoteric. The problem isn’t that users see dense-sounding things like “directed acyclic graph of revisions”, it’s that they assume they can competently manipulate one without knowing what that means. I do think the interface could use cleanup, but can any ammount of cleanup prevent needing to know the mental model of git?
- tome 8y ago
  > I do think the interface could use cleanup, but can any ammount of cleanup prevent needing to know the mental model of git? Git's interface is far, far more complicated than its model. Personally I spent years not learning about the model because I thought it would be as complicated as the interface. When I realised that the model is basically as simple as what you get when you view the "network" on GitHub then I started loving Git.
  - seba_dos1 8y ago
    Exactly this. Git is pretty easy; at the same time, using Git isn't. If you skip learning the easy mental model, all you have left is hard interface, so in result you just struggle, because you can't even rely on your intuition to get how things work there.
  - amag 8y ago
    I've found that adding my own aliases that sound more akin to what I'm trying to achieve has helped greatly with this, e.g. I have 'discard' as an alias for 'checkout --'.
- masklinn 8y ago
  Bullshit. The "mental model" has never been the issue with git, it's always been that the UI is garbage and a giant abstraction leak, requiring knowing the implementation details of the commands and the storage model to work with and step over footguns. Because rather than an actual, designed, considered UI, the porcelain is crummy shortcuts on sets of operations on the underlying storage (not mental) model. Mercurial has the same "DAG of revisions" model as git, and works just fine, because it has a good UI. Darcs has a more unusual mental model than git, and works just fine, because it has a good UI.
samontar 8y ago
Honestly have found it nothing but a pleasure to use. Not at all upset by the UI. It’s fine. Hg is fine. They’re easy enough to use that I never think about it and I rebase interactive daily and am comfortable with the reflog. It surprisingly didn’t take that long. I’ve never found myself backed into a corner and I suspect this is part of its success: some people have codebases where it’s a problem (branch names which are files, for instances) but most people don’t encounter this sort of thing and it works just fine.
colonelpopcorn 8y ago
I was surprised there was no mention of how to get out of a HEAD detached state. That seems to be my number one "oops, now I've got to delete and re-clone" problem.
- theamk 8y ago
  but... "git checkout master" and you are all done! why would you re-clone for that?
imhelpingu 8y ago
Can you give an example of a "footgun" that doesn't involve using a --force flag or "git reset --hard" without understanding what they do?
fizixer 8y ago
Revision control, in general, turns 2D code into 3D code. Git turns 2D code into 4D code. With great power comes great responsibility. And you have to impose rules on yourself regarding which areas of that power landscape you should explore and which areas to stay away from (to keep your sanity, productivity, keep the complexity under control, etc, etc). Flight rules, process workflows, protocols (both network protocols, and protocols of mission critical human activity), they all belong to the idea of limiting yourself to a set pattern of activity when dealing with something that can practically give you infinite possibilities. Because infinite possibilities give decision fatigue and analysis paralysis. By 2D code I mean code in a text editor: the two dimensions of lines and columns. By 3D code I mean: lines, columns, time (meaning commit timestamps) By 4D code I mean: lines, columns, time, time travel (you can go back to older commits and rewrite your revision history).
rw_grim 8y ago
They're have been attempts at cleaning it up; cogito, tig, and gitless. Why they haven't caught on, we'll never know...
liveoneggs 8y ago
"No technology can ever be too arcane or complicated for the black t-shirt crowd." <- not really Linus but hey

feintruled 8y ago

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.

marcodave 8y ago

But one of those shiny GUI was called GitHub, and it was the shiniest of the shiniest, so much that it make git usage ridiculously easy. At least on my experience.

smacktoward 8y ago
Git is very easy to use, right up to the moment when it really really is not.
- mikestew 8y ago
  Every SCM/SCC/VCS has a wall you'll hit eventually. Whoopsie, the merge went wrong. Whoopsie, didn't mean to check that in. Whoopsie,... Most version control systems will allow you to crash through that wall with a little damage, might slow you down a little, but you'll keep going. git's wall is thick, made of brick and reinforced concrete, and you'll be heading toward it at 200kph. You'll get going again eventually, once the metaphoric car gets glued back together. Non-metaphorically, my experience has been that with SVN, Mercurial, et. al., a few quick web searches and I'm on my way. With git, "wait a minute...run that by me again?" I've used git for going on a decade, and now that I'm in an SVN shop I do sorely miss it. But, man, it's got some sharp edges.
  - smacktoward 8y ago
    This is a good metaphorical version of what it's like introducing new people to Git: https://www.youtube.com/watch?v=92wPOsuHZ9Y https://www.youtube.com/watch?v=92wPOsuHZ9Y
  - kevin_thibedeau 8y ago
    I've never had to manually edit merge history in Git like SVN forces when merging complicated branch hierarchies. SVN is basically a half implemented VCS where the guts are exposed and you tread lightly whenever doing anything the original design didn't anticipate like ubiquitous merging.
saagarjha 8y ago

chrisseaton 8y ago

What 'footguns' are there? I find it pleasingly hard to accidentally delete anything, or get myself into any kind of corner when using Git. What am I missing?

lixtra 8y ago
Explain detached head like i’m 5 years old.
- XCabbage 8y ago
  Why should he have to? It's irrelevant to the point he's making, since a tool being conceptually difficult is not the same thing as it having footguns.
  - masklinn 8y ago
    > a tool being conceptually difficult is not the same thing as it having footguns. But the tool is not conceptually difficult. All the difficulty of git is in the trap its "UI" creates for no reason. The concepts are easy. I taught Darcs to a frontend/flash developer 15 years ago, and it's not because I'm a great teacher.
- xyzzy_plugh 8y ago
  Detached HEAD isn't complicated. It simply means there is nothing tracking the current line of work beyond the commit shas themselves. No branch is updated when you make commits. Conversely, attached HEAD means a branch is being updated whenever you make a commit, e.g. when you make commits on your local master.
  - iainmerrick 8y ago
    But why would I get into that state, and how do I get out without losing my work? Neither of those is obvious.
    - 8y ago

pjmlp 8y ago

Because Linux, basically.

finnthehuman 8y ago

It’s basically a manifestation of programmer arrogance that they’re just too damn smart to encounter a software learning curve again. Ever sat through user training on microsoft office? How to use email? The weird one-off enterprise apps that nobody else has ever heard of? They’re unbearably tedious to users that can get by in a new tool with a 5 minute crash course, intuition and light googling. Then git shows up and has the audacity to ask professionals to learn its mental model. Once you do the interface isn’t great, but not particularly esoteric. The problem isn’t that users see dense-sounding things like “directed acyclic graph of revisions”, it’s that they assume they can competently manipulate one without knowing what that means. I do think the interface could use cleanup, but can any ammount of cleanup prevent needing to know the mental model of git?

tome 8y ago
> I do think the interface could use cleanup, but can any ammount of cleanup prevent needing to know the mental model of git? Git's interface is far, far more complicated than its model. Personally I spent years not learning about the model because I thought it would be as complicated as the interface. When I realised that the model is basically as simple as what you get when you view the "network" on GitHub then I started loving Git.
- seba_dos1 8y ago
  Exactly this. Git is pretty easy; at the same time, using Git isn't. If you skip learning the easy mental model, all you have left is hard interface, so in result you just struggle, because you can't even rely on your intuition to get how things work there.
- amag 8y ago
  I've found that adding my own aliases that sound more akin to what I'm trying to achieve has helped greatly with this, e.g. I have 'discard' as an alias for 'checkout --'.
masklinn 8y ago
Bullshit. The "mental model" has never been the issue with git, it's always been that the UI is garbage and a giant abstraction leak, requiring knowing the implementation details of the commands and the storage model to work with and step over footguns. Because rather than an actual, designed, considered UI, the porcelain is crummy shortcuts on sets of operations on the underlying storage (not mental) model. Mercurial has the same "DAG of revisions" model as git, and works just fine, because it has a good UI. Darcs has a more unusual mental model than git, and works just fine, because it has a good UI.

samontar 8y ago

Honestly have found it nothing but a pleasure to use. Not at all upset by the UI. It’s fine. Hg is fine. They’re easy enough to use that I never think about it and I rebase interactive daily and am comfortable with the reflog. It surprisingly didn’t take that long. I’ve never found myself backed into a corner and I suspect this is part of its success: some people have codebases where it’s a problem (branch names which are files, for instances) but most people don’t encounter this sort of thing and it works just fine.

colonelpopcorn 8y ago

I was surprised there was no mention of how to get out of a HEAD detached state. That seems to be my number one "oops, now I've got to delete and re-clone" problem.

theamk 8y ago
but... "git checkout master" and you are all done! why would you re-clone for that?

imhelpingu 8y ago

Can you give an example of a "footgun" that doesn't involve using a --force flag or "git reset --hard" without understanding what they do?

fizixer 8y ago

Revision control, in general, turns 2D code into 3D code. Git turns 2D code into 4D code. With great power comes great responsibility. And you have to impose rules on yourself regarding which areas of that power landscape you should explore and which areas to stay away from (to keep your sanity, productivity, keep the complexity under control, etc, etc). Flight rules, process workflows, protocols (both network protocols, and protocols of mission critical human activity), they all belong to the idea of limiting yourself to a set pattern of activity when dealing with something that can practically give you infinite possibilities. Because infinite possibilities give decision fatigue and analysis paralysis. By 2D code I mean code in a text editor: the two dimensions of lines and columns. By 3D code I mean: lines, columns, time (meaning commit timestamps) By 4D code I mean: lines, columns, time, time travel (you can go back to older commits and rewrite your revision history).

rw_grim 8y ago

They're have been attempts at cleaning it up; cogito, tig, and gitless. Why they haven't caught on, we'll never know...

liveoneggs 8y ago

"No technology can ever be too arcane or complicated for the black t-shirt crowd." <- not really Linus but hey