7 ms·

> During the last 5 years, many GUIs have filled in this gap, making it increasingly likely to find people completely stuck because they miss knowledge of the f

by annnnd 10y ago

> During the last 5 years, many GUIs have filled in this gap, making it increasingly likely to find people completely stuck because they miss knowledge of the foundations. Arguably, these GUIs became popular because Git by itself offers awful UX. I am all for obscure commands and switches (I use Linux and prefer CLI to mouse), but Git really took it to the next level. And it's not as if it couldn't be done better (as Mercurial shows). As a user I don't want to know the intrinsic details about how some system is implemented. I just don't care - give me an external model which helps me use it, and leave it at that. I have my own code I need to worry about. If most users get the "wrong" mental model when using Git, then the problem lies with Git, not with users. </rant>

jahnu 10y ago
Git is a master example of why leaky abstractions are bad.
- qznc 10y ago
  People complain about missing abstractions, not leaky ones. Mercurial has leaky abstractions imho. A Mercurial changeset ("commit" in git terminology) has a branch property. In git a commit does not belong to a certain branch. With both SCMs, most changesets/commits are on multiple branches, thus I consider the Mercurial abstraction leaky. Mercurial people seem to like this, but it just doesn't fit my mental model.
  - Siecje 10y ago
    I think you are talking about named branches in Mercurial. You can use Mercurial without named branches and use bookmarks instead.
    - marcinkuzminski 10y ago
      Exactly, there is the flexibility. IF you need to track source of commits together with the permanent branch info you use Mercurial branches, if you want a "symlink branches" in GIT style, bookmarks are the way to go. It works nice with Pull requests when you can move branch pointer after rebase or updates of commits.
nhaehnle 10y ago
It's arguably become much better in terms of "native" GUIs that don't try to hide the details. Between gitk and git-gui, what's really missing? (Both of those examples could probably be polished here and there, but the basic concepts are sound.) Also, you really don't have to know the intrinsic details of how Git is implemented. What you do need to know is its model. The "native" model of Git is already very clean and sound, tacking on an external model with subtle incompatibilities is precisely what will make life difficult.
derefr 10y ago
A large part of the point of Git (in contrast to earlier tools like CVS) is that the internal data model that it enforces is one that works in the long term in distributed project settings. Distributed source control requires a kind of hygiene, much like dental hygiene, or like cryptographic security. In the practice of hygiene, what's convenient is usually opposed to what's sustainable. Hygiene is effectively the set of discoveries of un-natural or non-intuitive ways to do things that work better than the equivalent intuitive/natural practices. Thus, any process that is "hygenic" is going to cause at least a little bit of pain or annoyance to follow—if it didn't, it'd be "natural." And that's the fundamental problem with Git: that it tries to paper over the fact that it's "hygenic" by presenting itself as something seemingly "natural." People have the wrong mental model of Git because Git tries to meet them in the middle, by translating its (correct, sustainable) internal model into (broken, leaky) familiar abstractions. Git isn't your friend. Git is your toothbrush. Imagine your dental hygienist telling you they're disappointed in how infrequently and badly you're brushing your teeth. The right response to that isn't blaming the hygienist for making toothbrushes annoying to use, right? It's shame, shame that you haven't bothered to overcome the stupid stubborn ignorance getting in the way of you taking better care of your teeth. Shame that you can't "meet your toothbrush where it lives." Meet Git where it lives.
- Tomte 10y ago
  > Imagine your dental hygienist telling you they're disappointed in how infrequently and badly you're brushing your teeth. The right response to that isn't blaming the hygienist for making toothbrushes annoying to use, right? I'm very happy with my electric toothbrush, a purely UI/UX improvement to the problem of toothbrushing. There's no reason to take it away from me, just to make me realize the pure awesomeness of the procedure of toothbrushing.
  - derefr 10y ago
    An electric toothbrush doesn't paper over the abstraction of brushing teeth. The thing the electric toothbrush is doing for you is a clear, 1:1 automation of the thing you do yourself with a manual toothbrush. This isn't true of git's high-level commands. If Git was a tooth-cleaning tool, it wouldn't be one that helps you to brush your own teeth. Instead, Git['s high-level command set] would be a fancy machine that asks you to take your teeth out (and hopefully they're dentures), put them into a black box, and then they'll come out cleaned. But sometimes they come out with the teeth rearranged and it's hard to understand why. Sometimes they come out tasting of fluoride and merge-commits. Sometimes you have to take your tongue-ring out before Git will accept your teeth. It's all very mysterious. Which is silly. Inside the box, Git is brushing your teeth. Inside the box, a very simple thing is going on. It's the abstraction layer that's complicated and unintuitive. The "mystery" is all in how they map their black-box interface to the tooth-brushing internals. If Git actually was an electric toothbrush—a way to accelerate and ease brushing teeth, but keeping 1:1 clarity on what's going on, and complete control of the result—then nobody would ever be confused about Git. It'd be slightly harder to use than a black box that you put whole dentures into—in about the same way that sed(1) is harder to use than the "Find and Replace" in a text editor—but those familiar with it wouldn't find the workflow any more strenuous.
deleted 10y ago
[deleted]
irrational 10y ago
As I'm reading these comments I can't help but wonder, why hasn't anyone come up with a sane git cli interface that people can use in place of the standard git cli commands (of course the sane git cli commands would just call the "old" git cli commands under the hood)?
- skoczymroczny 10y ago
  Because such abstraction will always be leaky and when things break, you will need to get down to the git level anyway. Also it would be harder to find contributors to your project if you don't use git directly, or you'd have to maintain two sets of instructions, for git users and for easy-git-whatever users. It's kind of like wondering, "why hasn't anyone come up with a sane language that people can use in place of Javascript (of course the same language would just use old Javascript under the hood". Sure, there is TypeScript and like, and it solves many problems, but it introduces others.
  - irrational 10y ago
    Sure you would need somebody on the team who can get down to the git level when things go wrong, but do all the rest of the team members have to work at that level? Not everyone has to be a DBA to work with a database. It seems that we could have a level of abstraction for the majority of use cases.

by annnnd 10y ago

jahnu 10y ago

Git is a master example of why leaky abstractions are bad.

qznc 10y ago
People complain about missing abstractions, not leaky ones. Mercurial has leaky abstractions imho. A Mercurial changeset ("commit" in git terminology) has a branch property. In git a commit does not belong to a certain branch. With both SCMs, most changesets/commits are on multiple branches, thus I consider the Mercurial abstraction leaky. Mercurial people seem to like this, but it just doesn't fit my mental model.
- Siecje 10y ago
  I think you are talking about named branches in Mercurial. You can use Mercurial without named branches and use bookmarks instead.
  - marcinkuzminski 10y ago
    Exactly, there is the flexibility. IF you need to track source of commits together with the permanent branch info you use Mercurial branches, if you want a "symlink branches" in GIT style, bookmarks are the way to go. It works nice with Pull requests when you can move branch pointer after rebase or updates of commits.

nhaehnle 10y ago

It's arguably become much better in terms of "native" GUIs that don't try to hide the details. Between gitk and git-gui, what's really missing? (Both of those examples could probably be polished here and there, but the basic concepts are sound.) Also, you really don't have to know the intrinsic details of how Git is implemented. What you do need to know is its model. The "native" model of Git is already very clean and sound, tacking on an external model with subtle incompatibilities is precisely what will make life difficult.

derefr 10y ago

A large part of the point of Git (in contrast to earlier tools like CVS) is that the internal data model that it enforces is one that works in the long term in distributed project settings. Distributed source control requires a kind of hygiene, much like dental hygiene, or like cryptographic security. In the practice of hygiene, what's convenient is usually opposed to what's sustainable. Hygiene is effectively the set of discoveries of un-natural or non-intuitive ways to do things that work better than the equivalent intuitive/natural practices. Thus, any process that is "hygenic" is going to cause at least a little bit of pain or annoyance to follow—if it didn't, it'd be "natural." And that's the fundamental problem with Git: that it tries to paper over the fact that it's "hygenic" by presenting itself as something seemingly "natural." People have the wrong mental model of Git because Git tries to meet them in the middle, by translating its (correct, sustainable) internal model into (broken, leaky) familiar abstractions. Git isn't your friend. Git is your toothbrush. Imagine your dental hygienist telling you they're disappointed in how infrequently and badly you're brushing your teeth. The right response to that isn't blaming the hygienist for making toothbrushes annoying to use, right? It's shame, shame that you haven't bothered to overcome the stupid stubborn ignorance getting in the way of you taking better care of your teeth. Shame that you can't "meet your toothbrush where it lives." Meet Git where it lives.

Tomte 10y ago
> Imagine your dental hygienist telling you they're disappointed in how infrequently and badly you're brushing your teeth. The right response to that isn't blaming the hygienist for making toothbrushes annoying to use, right? I'm very happy with my electric toothbrush, a purely UI/UX improvement to the problem of toothbrushing. There's no reason to take it away from me, just to make me realize the pure awesomeness of the procedure of toothbrushing.
- derefr 10y ago
  An electric toothbrush doesn't paper over the abstraction of brushing teeth. The thing the electric toothbrush is doing for you is a clear, 1:1 automation of the thing you do yourself with a manual toothbrush. This isn't true of git's high-level commands. If Git was a tooth-cleaning tool, it wouldn't be one that helps you to brush your own teeth. Instead, Git['s high-level command set] would be a fancy machine that asks you to take your teeth out (and hopefully they're dentures), put them into a black box, and then they'll come out cleaned. But sometimes they come out with the teeth rearranged and it's hard to understand why. Sometimes they come out tasting of fluoride and merge-commits. Sometimes you have to take your tongue-ring out before Git will accept your teeth. It's all very mysterious. Which is silly. Inside the box, Git is brushing your teeth. Inside the box, a very simple thing is going on. It's the abstraction layer that's complicated and unintuitive. The "mystery" is all in how they map their black-box interface to the tooth-brushing internals. If Git actually was an electric toothbrush—a way to accelerate and ease brushing teeth, but keeping 1:1 clarity on what's going on, and complete control of the result—then nobody would ever be confused about Git. It'd be slightly harder to use than a black box that you put whole dentures into—in about the same way that sed(1) is harder to use than the "Find and Replace" in a text editor—but those familiar with it wouldn't find the workflow any more strenuous.

deleted 10y ago

[deleted]

irrational 10y ago

As I'm reading these comments I can't help but wonder, why hasn't anyone come up with a sane git cli interface that people can use in place of the standard git cli commands (of course the sane git cli commands would just call the "old" git cli commands under the hood)?

skoczymroczny 10y ago
Because such abstraction will always be leaky and when things break, you will need to get down to the git level anyway. Also it would be harder to find contributors to your project if you don't use git directly, or you'd have to maintain two sets of instructions, for git users and for easy-git-whatever users. It's kind of like wondering, "why hasn't anyone come up with a sane language that people can use in place of Javascript (of course the same language would just use old Javascript under the hood". Sure, there is TypeScript and like, and it solves many problems, but it introduces others.
- irrational 10y ago
  Sure you would need somebody on the team who can get down to the git level when things go wrong, but do all the rest of the team members have to work at that level? Not everyone has to be a DBA to work with a database. It seems that we could have a level of abstraction for the majority of use cases.