7 ms·

I have an admission to make: I don't understand git. By this I mean I have a few simple commands I use (status/add/commit/push/pull) and if I try to do anything

I have an admission to make: I don't understand git. By this I mean I have a few simple commands I use (status/add/commit/push/pull) and if I try to do anything more complicated it always ends up with lots of complex error messages that I don't understand and me nuking the repository and starting again. So I think: there must be a better way. I have often thought about implementing a VCS. The idea behind one doesn't seem particularly complex to me (certainly it's simpler than programming languages). If I did I would quite probably use WYAG as a starting point. My first step would be to define the user's mental model -- i.e. what concepts they need to understand such that they can predict what the system will do. Then I would build a web-based UI that presents the status of the system to the user in terms of that model.

cmroanirgo 8y ago
I'm like you. I use SourceTree to get a 'visual grasp' on what I find to be the noise of git commands. However, if you're into command line, you can try fossil: it's got lots going for it. Your idea of a "user's mental model" might land you into trouble though, because all of us come from different backgrounds (subversion, SSafe, git, HG...) and they all maddeningly redefine terms in different ways (eg branch, forks, commits, checkout).
- cabalamat 8y ago
  > Your idea of a "user's mental model" might land you into trouble though If I do do this, I will explicitly lay out the user's metal model in the documentation at the start. Then it will be the user's fault if they can't be bothered to read it.
  - huffstler 8y ago
    While gits documentation might not lay out the model at the start, they certainly have documentation showing how everything works, complete with diagrams and such. As such... > Then it will be the user's fault if they can't be bothered to read it. can be applied to you about git technically. I think that's just me being a "little" pedantic though. It sounds like the issue you actually have is that the documentation isn't easily readable in one or two sittings, and you don't have the time (or can't be bothered) to go through it and learn it. Which I totally understand, everyone has different things they need to spend time on, most of the time learning Git isn't one of them.
    - cabalamat 8y ago
      > can be applied to you about git technically. I have read large parts of the git docs. I don't like them. This is not just the text: the low contract colours and hard-to-read fonts are also factors. > It sounds like the issue you actually have is that the documentation isn't easily readable in one or two sittings, and you don't have the time (or can't be bothered) to go through it and learn it. So how long should it take to learn a VCS? And how long does git take to learn?
- Nr7 8y ago
  Using a git client with a graphical user interface has definitely helped me "grok" git as well. I use Git Extensions myself.
AnIdiotOnTheNet 8y ago
Yeah, I too don't really understand git. It seems that it was developed without any concern for affording a good mental model of its operation to its users, and thus it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down. I know I could build a mental model of it if I put enough time into it, but who wants to do that when there's actually useful things to do? So instead when I have to use it to contribute to open source projects I have a sheet of notes with incantations to cover the specific things I've had to do with it in the past.
- cabalamat 8y ago
  > It seems that it was developed without any concern for affording a good mental model of its operation to its users I think Linus' design goal was something that runs as quickly/efficiently as possible on large repositories. > it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down My feeling too!
  - influx 8y ago
    No, his design goal was to create a vcs for the Linux kernel. Frankly most people use git like svn version 2, completely skipping the distributed parts of it. Git actually doesn’t scale to really huge monorepos.
    - Deganta 8y ago
      That's because most users don't actually need the distributed part of git. For most projects the sanest solution is to have a single master repository that all users pull/push from/to. IMHO the only real advantages over SVN for most users are the better branch/merge functions.
      - jancsika 8y ago
        In other words-- git is so good at being decentralized you only notice the consequences in the improved branch/merge UX.
neals 8y ago
I think this is a large majority of Git users. The last company I worked at had 30 good developers, 1 of which I think really deeply understood git. So I guess 97% of users don't really get git.
- cabalamat 8y ago
  > The last company I worked at had 30 good developers, 1 of which I think really deeply understood git. I think this is really damning. Developers understand complex languages/compilers like C++, Python, Java, etc, all of which have a good deal more intrinsic complexity than a VCS. So if a VCS isn't understood, it is badly designed.
  - frosted-flakes 8y ago
    It's because it's so opaque and inconsistent. If git was a program like Microsoft Word, where every available action is easily discoverable and the current state is obvious, then it wouldn't be so bad. Something like what Nikita Tonsky wrote in an article called "Reinventing Git Interface"[0], which has a lot of good ideas. [0] http://tonsky.me/blog/reinventing-git-interface/ http://tonsky.me/blog/reinventing-git-interface/
derekp7 8y ago
Look for a video on YouTube called Git Happens. I've found it fairly effective with my coworkers. It doesn't go over the command syntax, but instead dives into a logical overview of the underlying data structures.
rezeroed 8y ago
I'm not much better. I knew SVN inside out. I've read up on git internals, poked around with them, but eventually forget it all because 99% of the time I only use the same five commands. It's a real iceberg, Pareto principle piece of software for me.
rsp1984 8y ago
Just curious: Have you tried any of the git GUIs out there? There are many good ones: Fork, Git Tower, GitX-dev. I guess I would be lost as well just using the command line.
- cabalamat 8y ago
  > Have you tried any of the git GUIs out there? I regularly use Giggle. > Fork, Git Tower, GitX-dev None of these work on Linux. GitX-dev also has a website I have difficulty reading.
js2 8y ago
Perhaps the Git Parable will help: http://tom.preston-werner.com/2009/05/19/the-git-parable.html http://tom.preston-werner.com/2009/05/19/the-git-parable.htm... To provide an alternate viewpoint, I have never had trouble with Git. I’m a bottom-up how-does-this-thing-work sort of person so when I first started using Git, I sought to understand how it worked. That part of Git is pretty easy to understand. Knowing that made its CLI a lot easier to grok. Of course, at the time I was having to use ClearCase at work and Subversion on the side so Git, IMO, was a vast improvement to either of those tools.
elviejo 8y ago
I'm in the same boat. I could teach subversion in 1 hour and people would get it. I can't teach git in a whole week. So in the end my students use the same 5 commands.
tsukikage 8y ago
git is to version control systems as vim is to text editing or dwarf fortress is to god sims. (dear everyone here and elsewhere recommending git incantations "but of course you have to know what you're doing": if you regularly have to take a backup of your working area before interacting with the vcs, because the interaction may do things you did not intend from which the simplest way back is to reset hard and start over, I humbly suggest that the vcs has failed in its primary purpose)
- chousuke 8y ago
  I'm not sure if I'm reading your comment right, but if you're going to do something that might result in a mess (such as a merge or a rebase) the sane thing to do is not to have anything uncommitted in your workdir; that way you can always retry, undo and experiment, and the VCS is doing exactly what it's supposed to be doing. It's something subversion can't do last I checked, so whenever I need to do a complicated operation with SVN, I import the local state into a git repo first :P

cmroanirgo 8y ago

I'm like you. I use SourceTree to get a 'visual grasp' on what I find to be the noise of git commands. However, if you're into command line, you can try fossil: it's got lots going for it. Your idea of a "user's mental model" might land you into trouble though, because all of us come from different backgrounds (subversion, SSafe, git, HG...) and they all maddeningly redefine terms in different ways (eg branch, forks, commits, checkout).

cabalamat 8y ago
> Your idea of a "user's mental model" might land you into trouble though If I do do this, I will explicitly lay out the user's metal model in the documentation at the start. Then it will be the user's fault if they can't be bothered to read it.
- huffstler 8y ago
  While gits documentation might not lay out the model at the start, they certainly have documentation showing how everything works, complete with diagrams and such. As such... > Then it will be the user's fault if they can't be bothered to read it. can be applied to you about git technically. I think that's just me being a "little" pedantic though. It sounds like the issue you actually have is that the documentation isn't easily readable in one or two sittings, and you don't have the time (or can't be bothered) to go through it and learn it. Which I totally understand, everyone has different things they need to spend time on, most of the time learning Git isn't one of them.
  - cabalamat 8y ago
    > can be applied to you about git technically. I have read large parts of the git docs. I don't like them. This is not just the text: the low contract colours and hard-to-read fonts are also factors. > It sounds like the issue you actually have is that the documentation isn't easily readable in one or two sittings, and you don't have the time (or can't be bothered) to go through it and learn it. So how long should it take to learn a VCS? And how long does git take to learn?
Nr7 8y ago
Using a git client with a graphical user interface has definitely helped me "grok" git as well. I use Git Extensions myself.

AnIdiotOnTheNet 8y ago

Yeah, I too don't really understand git. It seems that it was developed without any concern for affording a good mental model of its operation to its users, and thus it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down. I know I could build a mental model of it if I put enough time into it, but who wants to do that when there's actually useful things to do? So instead when I have to use it to contribute to open source projects I have a sheet of notes with incantations to cover the specific things I've had to do with it in the past.

cabalamat 8y ago
> It seems that it was developed without any concern for affording a good mental model of its operation to its users I think Linus' design goal was something that runs as quickly/efficiently as possible on large repositories. > it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down My feeling too!
- influx 8y ago
  No, his design goal was to create a vcs for the Linux kernel. Frankly most people use git like svn version 2, completely skipping the distributed parts of it. Git actually doesn’t scale to really huge monorepos.
  - Deganta 8y ago
    That's because most users don't actually need the distributed part of git. For most projects the sanest solution is to have a single master repository that all users pull/push from/to. IMHO the only real advantages over SVN for most users are the better branch/merge functions.
    - jancsika 8y ago
      In other words-- git is so good at being decentralized you only notice the consequences in the improved branch/merge UX.

neals 8y ago

I think this is a large majority of Git users. The last company I worked at had 30 good developers, 1 of which I think really deeply understood git. So I guess 97% of users don't really get git.

cabalamat 8y ago
> The last company I worked at had 30 good developers, 1 of which I think really deeply understood git. I think this is really damning. Developers understand complex languages/compilers like C++, Python, Java, etc, all of which have a good deal more intrinsic complexity than a VCS. So if a VCS isn't understood, it is badly designed.
- frosted-flakes 8y ago
  It's because it's so opaque and inconsistent. If git was a program like Microsoft Word, where every available action is easily discoverable and the current state is obvious, then it wouldn't be so bad. Something like what Nikita Tonsky wrote in an article called "Reinventing Git Interface"[0], which has a lot of good ideas. [0] http://tonsky.me/blog/reinventing-git-interface/ http://tonsky.me/blog/reinventing-git-interface/

derekp7 8y ago

Look for a video on YouTube called Git Happens. I've found it fairly effective with my coworkers. It doesn't go over the command syntax, but instead dives into a logical overview of the underlying data structures.

rezeroed 8y ago

I'm not much better. I knew SVN inside out. I've read up on git internals, poked around with them, but eventually forget it all because 99% of the time I only use the same five commands. It's a real iceberg, Pareto principle piece of software for me.

rsp1984 8y ago

Just curious: Have you tried any of the git GUIs out there? There are many good ones: Fork, Git Tower, GitX-dev. I guess I would be lost as well just using the command line.

cabalamat 8y ago
> Have you tried any of the git GUIs out there? I regularly use Giggle. > Fork, Git Tower, GitX-dev None of these work on Linux. GitX-dev also has a website I have difficulty reading.

js2 8y ago

Perhaps the Git Parable will help: http://tom.preston-werner.com/2009/05/19/the-git-parable.html http://tom.preston-werner.com/2009/05/19/the-git-parable.htm... To provide an alternate viewpoint, I have never had trouble with Git. I’m a bottom-up how-does-this-thing-work sort of person so when I first started using Git, I sought to understand how it worked. That part of Git is pretty easy to understand. Knowing that made its CLI a lot easier to grok. Of course, at the time I was having to use ClearCase at work and Subversion on the side so Git, IMO, was a vast improvement to either of those tools.

elviejo 8y ago

I'm in the same boat. I could teach subversion in 1 hour and people would get it. I can't teach git in a whole week. So in the end my students use the same 5 commands.

tsukikage 8y ago

git is to version control systems as vim is to text editing or dwarf fortress is to god sims. (dear everyone here and elsewhere recommending git incantations "but of course you have to know what you're doing": if you regularly have to take a backup of your working area before interacting with the vcs, because the interaction may do things you did not intend from which the simplest way back is to reset hard and start over, I humbly suggest that the vcs has failed in its primary purpose)

chousuke 8y ago
I'm not sure if I'm reading your comment right, but if you're going to do something that might result in a mess (such as a merge or a rebase) the sane thing to do is not to have anything uncommitted in your workdir; that way you can always retry, undo and experiment, and the VCS is doing exactly what it's supposed to be doing. It's something subversion can't do last I checked, so whenever I need to do a complicated operation with SVN, I import the local state into a git repo first :P