6 ms·

The Git version control system has been causing us misery for 15+ years. I think this is uncharitable at best. It was a huge step forward compared to then popu

by zoul 4y ago

The Git version control system has been causing us misery for 15+ years. I think this is uncharitable at best. It was a huge step forward compared to then popular VCSs such as Subversion, I have loved working with Git since it was created and I still enjoy working with it every day.

arxanas 4y ago
Mercurial has been around for approximately the same length of time, and from a UX perspective, I find it to be much superior to Git, which was largely built in terms of "what is the easiest way to solve this problem from an implementation perspective", rather from the user's standpoint. Of course, Git won for a reason, but I doubt that it wouldn't have still won had it incorporated some UX design ideas from Mercurial or elsewhere. > I have loved working with Git since it was created and I still enjoy working with it every day. I have been profoundly frustrated by working with Git every day, hence the article, and the linked set of tools which I wrote to improve my workflow. Not even because its mental model is hard to grasp or that the UI is poor, but because it doesn't even streamline the kinds of workflows that it should be good at (in the article, and discussed in its own `gitworkflows` man page).
- Beltalowda 4y ago
  > Of course, Git won for a reason 1. Linus Torvalds wrote it 2. GitHub 3. Linus Torvalds wrote it To be fair, there are some real differences; e.g. there is no easy "hg rebase" by design, and whether that's a good or bad thing has been a topic of contention for about 15 years. But that Linus wrote it gave it a huge boost, and GitHub really was much better than many things that came before it (and arguably, still is).
  - murderfs 4y ago
    Having the kernel as an anchor customer definitely helped, but there's also the reason that Linus wrote git in the first place, and that's that every other competitor was horrendously slow by comparison.
    - Beltalowda 4y ago
      git, mercurial, and bazaar were all released at pretty much the same time (within weeks of each other in March/April 2005). AFAIK all in response to the whole Bitkeeper situation at the time. I don't think performance was the main motivator; from what I recall it was mostly that Linus felt that the subversion model was "completely broken" and that there weren't any good distributed "bitkeeper-like" tools out there (and then, suddenly, there were three).
      - murderfs 4y ago
        Linus was looking at monotone as an alternative to BitKeeper, but in his words "performance was so horrendously bad that [he] tried it for a day and realized [he] cannot use it": https://youtu.be/4XpnKHJAok8?t=711 https://youtu.be/4XpnKHJAok8?t=711
    - amenod 4y ago
      Mercurial wasn't (at least for the projects I used it for).
      - acdha 4y ago
        It was very noticeably slower on all but the smallest projects. I started with it but switched to Git later for some open source work and that was one of the first impressions I had.
        Beltalowda 4y ago
        According to Facebook Mercurial was faster for them, but that was in 2014 and they had to put work in to actually make it fast. Their use case is rather outside the mainstream of course. "When we first started working on Mercurial, we found that it was slower than Git in several notable areas. To narrow this performance gap, we’ve contributed over 500 patches to Mercurial over the last year and a half." https://engineering.fb.com/2014/01/07/core-data/scaling-mercurial-at-facebook/ https://engineering.fb.com/2014/01/07/core-data/scaling-merc... Personally I can't recall any serious performance difference after I switched from mercurial (which included some large-ish repos) to git, but it's been quite a few years ago and perhaps I just forgot.
  - foobarbecue 4y ago
    Torvalds.
  - ilyt 4y ago
    Git is very much "here are tools, do what they want with them". There are no safety scissors included and the user must understand the problem to solve it. And the tools themselves are getting better over time, but you still need to understand what exactly you're doing, there is not much DWIM there and not that many shortcuts and no undo button. Like the one I use semi often (aliased to re) is "git reset HEAD~1". If you read the Git book, you know what reset does, you know that HEAD is where you currently are, and you know that "~1" means "commit before". So you tell git to reset current tree to commit before the one you're currently on (essentially "undo commit"). Actually, having "git undo" to "revert whatever I just done, regardless of what it was" and "--explain" ("tell me what I am about to do") would probably help a lot...
  - gpderetta 4y ago
    0. Git is fast 0.5. it doesn't get in the way of getting things done (at least most of the time)
  - EdiX 4y ago
    1. Git was faster than mercurial and bazar, eventually mercurial became fast but at that point it was too late 2. Git had a better svn backend, you could try git and get benefits from it even if your company used svn 3. Git did a lot of things that other dvcs didn't do (rebases, partial commits, history edits, local branches) A lot of the UI simplicity of other tools rests on not doing (3). For example, OP awards negative points for rebase but as far as I am concerned I won't even consider using a UI that doesn't support rebase.
- kqr 4y ago
  > I doubt that it wouldn't have still won had it incorporated some UX design ideas from Mercurial or elsewhere. I don't. This is "worse is better" at its core! https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html Simplicity of implementation prioritised over simplicity of interface can take you a lot further than the other way around, in a fast-changing, experimenting environment.
  - deleted 4y ago
    [deleted]
- ilyt 4y ago
  I must be weird one. I clicked with Git immediately but didn't gel with SVN/CVS at all. I do have a bunch of aliases and one added command (shortcut to deleting some stuff) but nothing really more complex that shortening up commonly used stuff.
- guitarbill 4y ago
  I have found this to be a common assertion, but my experience has been different. Mercurial Queues exists and people use(d) it. It has many, many more footguns than Git, and it's shockingly easy to loose work. The fact that this was ever acceptable is interesting. Phabricator is not good, or at least not as good GitLab, GitHub, or Gerrit (IMO). This is important, because Git alone is half the picture nowadays. The extensibility of Mercurial is also interesting, and leads to codebase-specific commands. This is maybe good for long-term developers, but makes onboarding new hires just that much harder. So Mercurial's UX being that much better than Git is - in my very limited experience - a myth.
- acdha 4y ago
  > Mercurial has been around for approximately the same length of time, and from a UX perspective, I find it to be much superior to Git I started using Mercurial as the first serious DVCS I used (dabbling earlier with things like bzr) and my experience doesn’t support this at all. I think it’s hard to underestimate the degree to which familiarity skews these assessments, especially with the additional confounding factors of project custom and experience. If you first used Git when contributing to a larger or more complex project than you were used to, it’s easy to misattribute the challenges to the tool and forget that everything got easier with experience using any DVCS. This is especially true for the not uncommon case where the problem is really that someone has strong opinions about how they think the tool should work and refuses to learn its actual design - I’ve known multiple people who ranted about Git who were also the guys who hacked up their development boxes before saying a project was too hard to install (“Python packaging is terrible!” “Didn’t you use sudo to overwrite /usr/bin/python with Python 3 right before getting all of those Unicode decode errors?”), or, in one notable case, say Debian packaging was broken after they manually upgrade MySQL and somehow managed to render the system unbootable.
  - arxanas 4y ago
    It's true that it's easy to forget one's early challenges, but we have empirical support that design decisions such as the staging area are objectively difficult for beginners to adopt. See https://investigating-archiving-git.gitlab.io/ https://investigating-archiving-git.gitlab.io/. Mercurial, of course, doesn't have a staging area.
    - acdha 4y ago
      Sure, but the staging area isn’t something you need to understand deeply to use Git since most common tools abstract it. Given how much more frequently the researchers’ subjects mentioned it, the big win would appear to be avoiding merge conflicts and better tools for reconciling them.
gigatexal 4y ago
Yeah ... I made an effort to try and understand Git as best as I could and have been quite comfortable in it for a while now. The CLI is not intuitive I get that but there's a lot of combined knowledge out there to get one out of a jam and good best practices like git-flow and such so not sure why all the angst here.
blkhp19 4y ago
It’s Stockholm syndrome mixed with you being an expert at a specific tool. The reality is, Git is unintuitive, and makes nearly every common thing the average person wants to do a complete pain in the ass. I understand you (and I) know how to get things done using Git, but as a society and a technically community, we should strive to make things better.
- Vanit 4y ago
  Agreed. Are the people defending it forgetting how often beginners end up in seemingly arcane states and need to just check out the branch again to return to sanity?
  - leipert 4y ago
    I dunno. Isn’t that what happens when you learn something? When learning to program, you end up in arcane states. When learning languages, you end up in arcane states. Even when learning how to drive, I ended up in arcane states. Obviously a bit of hyperbole, but when hopefully when you learn it and end up in weird states, you have a companion helping you to correct course.
  - ilyt 4y ago
    I'd imagine they'd do the same with any other DVCS. The concept of 2 people changing file that then needs to be merged is already hard enough for some, add distributed and you're in for a mess. From my experience as sysadmin the people having problem with it also highly correlate with people that just chmod 777 on server if something doesn't work and they don't understand why...
- growse 4y ago
  I feel like the entire concept of version control is "unintuitive", especially when you have multiple people working on the same codebase. What's worse, is that a lot of people who seem to be asking for the same workflows actually have slightly (or significantly!) different conceptual models of what they want, so we end up in this weird place where we think we all want the same thing but actually don't. If anything, git has clearly demonstrated that this is a complex space, and its perceived unusability stems from the fact that the operations it supports simply map onto basic graph operations.
dagmx 4y ago
Git is great once you get how it works. It’s also a UX nightmare. I work with tons of artists and engineers from the games and film industry. Teaching git to an artist is painful. UIs work, till they invariably fall apart and then they’re confused again in the command line. Also most UIs can’t abstract the ideas to a good easy system. Even a ton of very experienced engineers fall over when you touch rebasing etc… Now people will say use Perforce. Well that has its own issues around branching/streaming and integration for code etc… plus you’re tied to their systems, and I’m not convinced their UX is great either, just better. Plastic SCM seems to be the best so far but I haven’t really put it through the paces much. Anyway I guess my point is: git is a fantastic technology marred with bad UX. It’s much like GIMP or Blender back in the day that had terrible UX as well, but have since improved greatly. I’d love to see a rethink of the git UX at the UI level, that can guide even the most novice programmer through everything easily. Edit: also I know invariably someone will say to make my own Ui instead of complaining. I’ve tried. I’ve done some novel things but it’s really hard to do from a top down level without also rethinking some of the base interaction model. That’s a battle I think needs a lot of effort across the stack first.
- miohtama 4y ago
  Git is what a version control system would feel like if it were designed by kernel engineers who only knew C and Perl.
  - JTBooth 4y ago
    The joke is that that's who is was actually designed by, right?
- vijucat 4y ago
  > Teaching git to an artist is painful Ouch. Just use TortoiseSVN (+ svn)? I've had good success with it with business users.
- pronlover723 4y ago
  I'd argue you're using the wrong tool for the job. Git isn't designed for art assets in games, it's design for text based source code. Everything else is an afterthought. Games, especially AAA games, have 10s or 100s of terabytes of source assets. Git was never designed to handle this. git-lfs is a hack to try to help here but it's bolting on a workaround for a system that was never designed for managing art assets. It's also not designed to handle the fact that generally art assets are not mergable and so it doesn't handle coordination of editing assets (making sure 2 artists don't edit the same asset at the same time) No amount of UX is going to fix that git is the wrong tool for managing art assets. update: Googling for gamedev asset management this came up https://www.perforce.com/products/helix-dam https://www.perforce.com/products/helix-dam I have no idea if it's good or bad but hopefully it shows some ideas for how git is the wrong tool for art asset management
ilyt 4y ago
The fact there is no de-facto UI for people that don't understand tech IMO points to the problem being just too hard to grasp for average person. DVCS of any kind just requires certain bottom level of knowledge, if you don't have it you will just get yourself into trouble regardless on how good UI itself is.
deleted 4y ago
[deleted]
amenod 4y ago
Uncharitable or not, but it is true. Even with some improvements, git UI sucks to this day. Linus didn't care much about the chrome and had a special aversion against anything that smelled of SVN, including the names of the commands that actually made sense. And the worst thing is that Subversion wasn't even half bad - it was just bad for Linux kernel development. Most companies could easily use it today (and some still do). Additionally, Mercurial with its consistent UI is/was (imnsho) far superior to Git. Git won mostly because GitHub was lightyears ahead of everything else (and in many ways still is), not because git is any way better than hg.

by zoul 4y ago

arxanas 4y ago

Mercurial has been around for approximately the same length of time, and from a UX perspective, I find it to be much superior to Git, which was largely built in terms of "what is the easiest way to solve this problem from an implementation perspective", rather from the user's standpoint. Of course, Git won for a reason, but I doubt that it wouldn't have still won had it incorporated some UX design ideas from Mercurial or elsewhere. > I have loved working with Git since it was created and I still enjoy working with it every day. I have been profoundly frustrated by working with Git every day, hence the article, and the linked set of tools which I wrote to improve my workflow. Not even because its mental model is hard to grasp or that the UI is poor, but because it doesn't even streamline the kinds of workflows that it should be good at (in the article, and discussed in its own `gitworkflows` man page).

Beltalowda 4y ago
> Of course, Git won for a reason 1. Linus Torvalds wrote it 2. GitHub 3. Linus Torvalds wrote it To be fair, there are some real differences; e.g. there is no easy "hg rebase" by design, and whether that's a good or bad thing has been a topic of contention for about 15 years. But that Linus wrote it gave it a huge boost, and GitHub really was much better than many things that came before it (and arguably, still is).
- murderfs 4y ago
  Having the kernel as an anchor customer definitely helped, but there's also the reason that Linus wrote git in the first place, and that's that every other competitor was horrendously slow by comparison.
  - Beltalowda 4y ago
    git, mercurial, and bazaar were all released at pretty much the same time (within weeks of each other in March/April 2005). AFAIK all in response to the whole Bitkeeper situation at the time. I don't think performance was the main motivator; from what I recall it was mostly that Linus felt that the subversion model was "completely broken" and that there weren't any good distributed "bitkeeper-like" tools out there (and then, suddenly, there were three).
    - murderfs 4y ago
      Linus was looking at monotone as an alternative to BitKeeper, but in his words "performance was so horrendously bad that [he] tried it for a day and realized [he] cannot use it": https://youtu.be/4XpnKHJAok8?t=711 https://youtu.be/4XpnKHJAok8?t=711
  - amenod 4y ago
    Mercurial wasn't (at least for the projects I used it for).
    - acdha 4y ago
      It was very noticeably slower on all but the smallest projects. I started with it but switched to Git later for some open source work and that was one of the first impressions I had.
      - Beltalowda 4y ago
        According to Facebook Mercurial was faster for them, but that was in 2014 and they had to put work in to actually make it fast. Their use case is rather outside the mainstream of course. "When we first started working on Mercurial, we found that it was slower than Git in several notable areas. To narrow this performance gap, we’ve contributed over 500 patches to Mercurial over the last year and a half." https://engineering.fb.com/2014/01/07/core-data/scaling-mercurial-at-facebook/ https://engineering.fb.com/2014/01/07/core-data/scaling-merc... Personally I can't recall any serious performance difference after I switched from mercurial (which included some large-ish repos) to git, but it's been quite a few years ago and perhaps I just forgot.
- foobarbecue 4y ago
  Torvalds.
- ilyt 4y ago
  Git is very much "here are tools, do what they want with them". There are no safety scissors included and the user must understand the problem to solve it. And the tools themselves are getting better over time, but you still need to understand what exactly you're doing, there is not much DWIM there and not that many shortcuts and no undo button. Like the one I use semi often (aliased to re) is "git reset HEAD~1". If you read the Git book, you know what reset does, you know that HEAD is where you currently are, and you know that "~1" means "commit before". So you tell git to reset current tree to commit before the one you're currently on (essentially "undo commit"). Actually, having "git undo" to "revert whatever I just done, regardless of what it was" and "--explain" ("tell me what I am about to do") would probably help a lot...
- gpderetta 4y ago
  0. Git is fast 0.5. it doesn't get in the way of getting things done (at least most of the time)
- EdiX 4y ago
  1. Git was faster than mercurial and bazar, eventually mercurial became fast but at that point it was too late 2. Git had a better svn backend, you could try git and get benefits from it even if your company used svn 3. Git did a lot of things that other dvcs didn't do (rebases, partial commits, history edits, local branches) A lot of the UI simplicity of other tools rests on not doing (3). For example, OP awards negative points for rebase but as far as I am concerned I won't even consider using a UI that doesn't support rebase.
kqr 4y ago
> I doubt that it wouldn't have still won had it incorporated some UX design ideas from Mercurial or elsewhere. I don't. This is "worse is better" at its core! https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html Simplicity of implementation prioritised over simplicity of interface can take you a lot further than the other way around, in a fast-changing, experimenting environment.
- deleted 4y ago
  [deleted]
ilyt 4y ago
I must be weird one. I clicked with Git immediately but didn't gel with SVN/CVS at all. I do have a bunch of aliases and one added command (shortcut to deleting some stuff) but nothing really more complex that shortening up commonly used stuff.
guitarbill 4y ago
I have found this to be a common assertion, but my experience has been different. Mercurial Queues exists and people use(d) it. It has many, many more footguns than Git, and it's shockingly easy to loose work. The fact that this was ever acceptable is interesting. Phabricator is not good, or at least not as good GitLab, GitHub, or Gerrit (IMO). This is important, because Git alone is half the picture nowadays. The extensibility of Mercurial is also interesting, and leads to codebase-specific commands. This is maybe good for long-term developers, but makes onboarding new hires just that much harder. So Mercurial's UX being that much better than Git is - in my very limited experience - a myth.
acdha 4y ago
> Mercurial has been around for approximately the same length of time, and from a UX perspective, I find it to be much superior to Git I started using Mercurial as the first serious DVCS I used (dabbling earlier with things like bzr) and my experience doesn’t support this at all. I think it’s hard to underestimate the degree to which familiarity skews these assessments, especially with the additional confounding factors of project custom and experience. If you first used Git when contributing to a larger or more complex project than you were used to, it’s easy to misattribute the challenges to the tool and forget that everything got easier with experience using any DVCS. This is especially true for the not uncommon case where the problem is really that someone has strong opinions about how they think the tool should work and refuses to learn its actual design - I’ve known multiple people who ranted about Git who were also the guys who hacked up their development boxes before saying a project was too hard to install (“Python packaging is terrible!” “Didn’t you use sudo to overwrite /usr/bin/python with Python 3 right before getting all of those Unicode decode errors?”), or, in one notable case, say Debian packaging was broken after they manually upgrade MySQL and somehow managed to render the system unbootable.
- arxanas 4y ago
  It's true that it's easy to forget one's early challenges, but we have empirical support that design decisions such as the staging area are objectively difficult for beginners to adopt. See https://investigating-archiving-git.gitlab.io/ https://investigating-archiving-git.gitlab.io/. Mercurial, of course, doesn't have a staging area.
  - acdha 4y ago
    Sure, but the staging area isn’t something you need to understand deeply to use Git since most common tools abstract it. Given how much more frequently the researchers’ subjects mentioned it, the big win would appear to be avoiding merge conflicts and better tools for reconciling them.

gigatexal 4y ago

Yeah ... I made an effort to try and understand Git as best as I could and have been quite comfortable in it for a while now. The CLI is not intuitive I get that but there's a lot of combined knowledge out there to get one out of a jam and good best practices like git-flow and such so not sure why all the angst here.

blkhp19 4y ago

It’s Stockholm syndrome mixed with you being an expert at a specific tool. The reality is, Git is unintuitive, and makes nearly every common thing the average person wants to do a complete pain in the ass. I understand you (and I) know how to get things done using Git, but as a society and a technically community, we should strive to make things better.

Vanit 4y ago
Agreed. Are the people defending it forgetting how often beginners end up in seemingly arcane states and need to just check out the branch again to return to sanity?
- leipert 4y ago
  I dunno. Isn’t that what happens when you learn something? When learning to program, you end up in arcane states. When learning languages, you end up in arcane states. Even when learning how to drive, I ended up in arcane states. Obviously a bit of hyperbole, but when hopefully when you learn it and end up in weird states, you have a companion helping you to correct course.
- ilyt 4y ago
  I'd imagine they'd do the same with any other DVCS. The concept of 2 people changing file that then needs to be merged is already hard enough for some, add distributed and you're in for a mess. From my experience as sysadmin the people having problem with it also highly correlate with people that just chmod 777 on server if something doesn't work and they don't understand why...
growse 4y ago
I feel like the entire concept of version control is "unintuitive", especially when you have multiple people working on the same codebase. What's worse, is that a lot of people who seem to be asking for the same workflows actually have slightly (or significantly!) different conceptual models of what they want, so we end up in this weird place where we think we all want the same thing but actually don't. If anything, git has clearly demonstrated that this is a complex space, and its perceived unusability stems from the fact that the operations it supports simply map onto basic graph operations.

dagmx 4y ago

Git is great once you get how it works. It’s also a UX nightmare. I work with tons of artists and engineers from the games and film industry. Teaching git to an artist is painful. UIs work, till they invariably fall apart and then they’re confused again in the command line. Also most UIs can’t abstract the ideas to a good easy system. Even a ton of very experienced engineers fall over when you touch rebasing etc… Now people will say use Perforce. Well that has its own issues around branching/streaming and integration for code etc… plus you’re tied to their systems, and I’m not convinced their UX is great either, just better. Plastic SCM seems to be the best so far but I haven’t really put it through the paces much. Anyway I guess my point is: git is a fantastic technology marred with bad UX. It’s much like GIMP or Blender back in the day that had terrible UX as well, but have since improved greatly. I’d love to see a rethink of the git UX at the UI level, that can guide even the most novice programmer through everything easily. Edit: also I know invariably someone will say to make my own Ui instead of complaining. I’ve tried. I’ve done some novel things but it’s really hard to do from a top down level without also rethinking some of the base interaction model. That’s a battle I think needs a lot of effort across the stack first.

miohtama 4y ago
Git is what a version control system would feel like if it were designed by kernel engineers who only knew C and Perl.
- JTBooth 4y ago
  The joke is that that's who is was actually designed by, right?
vijucat 4y ago
> Teaching git to an artist is painful Ouch. Just use TortoiseSVN (+ svn)? I've had good success with it with business users.
pronlover723 4y ago
I'd argue you're using the wrong tool for the job. Git isn't designed for art assets in games, it's design for text based source code. Everything else is an afterthought. Games, especially AAA games, have 10s or 100s of terabytes of source assets. Git was never designed to handle this. git-lfs is a hack to try to help here but it's bolting on a workaround for a system that was never designed for managing art assets. It's also not designed to handle the fact that generally art assets are not mergable and so it doesn't handle coordination of editing assets (making sure 2 artists don't edit the same asset at the same time) No amount of UX is going to fix that git is the wrong tool for managing art assets. update: Googling for gamedev asset management this came up https://www.perforce.com/products/helix-dam https://www.perforce.com/products/helix-dam I have no idea if it's good or bad but hopefully it shows some ideas for how git is the wrong tool for art asset management

ilyt 4y ago

The fact there is no de-facto UI for people that don't understand tech IMO points to the problem being just too hard to grasp for average person. DVCS of any kind just requires certain bottom level of knowledge, if you don't have it you will just get yourself into trouble regardless on how good UI itself is.

deleted 4y ago

[deleted]

amenod 4y ago

Uncharitable or not, but it is true. Even with some improvements, git UI sucks to this day. Linus didn't care much about the chrome and had a special aversion against anything that smelled of SVN, including the names of the commands that actually made sense. And the worst thing is that Subversion wasn't even half bad - it was just bad for Linux kernel development. Most companies could easily use it today (and some still do). Additionally, Mercurial with its consistent UI is/was (imnsho) far superior to Git. Git won mostly because GitHub was lightyears ahead of everything else (and in many ways still is), not because git is any way better than hg.