5 ms·

Version control is arguably confusing for beginners, but building a shim instead of learning the tool isn't the answer in my head. I always struggle with "lowe

by lbotos 10y ago

Version control is arguably confusing for beginners, but building a shim instead of learning the tool isn't the answer in my head. I always struggle with "lowering the barrier of entry" and it's not a "I did it they need too do it" it's more of a "Usually high barriers mean it's complex, and learning how to understand complex things is important." If this was some new novel way to version that wasn't just pretty git, I'd be a lil more excited.

k__ 10y ago
It's like with IDEs. Eclipse has stuff like workspaces with multiple projects and others have simply projects. What to do with these workspaces? Same goes with Git. Simple VCS have central repositories and a working copy. Git has multiple repositories and every one of them can have a working copy. Other VCS don't have a stage, you simply commit your changes directly into your repository. It's not only that these tools have different commands and stuff like Mercurial or Subversion has easier commands etc. but they really have different concepts that need to be considered while working with these tools on a daily basis. But you don't have to internalize them on your first week or month working with them. When you got your project in the System it's mostly save and if you don't have complex workflows you can still reap the benefits of VCS with Git without knowing everything.
- ern 10y ago
  I may have misunderstood you, but you do realize that Mercurial is also a DVCS like git, right?
crawfordcomeaux 10y ago
I think there's a difference between learning something that's necessarily complex and learning something with an overly complex design. According to their analysis, the design changes they've made do away with unnecessary complexity.
StavrosK 10y ago
I don't understand this rationale. Are you saying that Git's UI is perfect, and there's no improving it? It's not, and gitless does, indeed, improve on it. We should be celebrating better UIs over important tools, not saying "I made great effort to learn it, therefore learning it with less effort is inferior". No. If it does everything Git does, but more easily, it is strictly superior.
- lbotos 10y ago
  What I'm saying is, Gitless is cool, BUT beginners are always looking for ways to cheat the effort. My point is, this is a great tool if you understand git, and want to use a shim, but for beginners, going straight to the shim is not good. >If it does everything Git does, but more easily, it is strictly superior. In the abstract I agree, but if an junior dev goes "oh, I just use gitless because it's easier" and DOESN'T understand git, it's a problem. That's my point.
  - pjc50 10y ago
    cheat the effort I'm always suspicious of arguments like this, because they have a Luddite quality to them. Isn't sending email versus handwritten postal mail "cheating the effort" of communication? git is a lot of effort to learn because its command line is inconsistent and it is frequently unclear what it has done, why and how to recover from it. It is worth asking if this is really necessary. If a system has a high percentage of beginners pressing the wrong button and losing time and effort as a result, maybe someone should move the buttons?
    - StavrosK 10y ago
      This is spot on, thank you. The git porcelain is very inconsistent between commands, and that really muddies the view of the underlying model. I would argue that a cleaner porcelain would lead to more easily building a mental model of the data structures.
- nickpsecurity 10y ago
  Well-said. We also know that git was originally hacked together in two weeks after Torvalds had to ditch the better-designed product they were using, Bitkeeper. It's almost as if a bunch of Linux developers kept hacking stuff into it with no concern for UX and telling people they were idiots if they didn't like mastering unnecessary complexity. Meanwhile, unlike Git, I understood most of Gitless's commands before the tutorial started explaining them. Opposite experience I got with Git tutorials where I kept questioning why it would be done a certain, unintuitive way. This is definitely an improvement.
masklinn 10y ago
In my previous job, I taught darcs to a designer/graphics artist. It took about half an hour to go through the CLI, and after that he used it successfully and asked me maybe a pair of questions ever. Now the guy was pretty technical (part of his job was AS development), but he was not a developer. Darcs's and Git's fundamentals are not that different[0], but Darcs's CLI actually makes sense in and of itself independent from the implementation details, and when it diverges from the older standard (e.g. SVN) it's so that commands make more sense, not less. Meanwhile Git has taken pretty much the opposite tack. Git's porcelain is a giant steaming roasted turd sandwich, no other DVCS has such a complex, hostile and nonsensical CLI that people tell you you're supposed to learn it from the storage model up and then it'll make sense. Don't try to shift the buck to VCS/DVCS concepts, while they are complex Git's CLI goes a great way towards making them nonsensical to beginners and non-beginners alike. I routinely used three different DVCS before I had to take the plunge into Git, and it was still a fucking pain in the ass. And that's a problem at every level of resolutions, just compare the hot mess that is gitrevisions(7) to mercurial's (more powerful, more flexible, more readable and more regular) revsets. It's not like revsets are a genius's flash of inspiration either, "hey I'm trying to manipulate sets of revisions, how about I manipulate them as sets?" We're not talking turing award worthy discovery here. [0] well they kinda are, but by and large the fundamental differences are irrelevant to basic day-to-day use.
- petre 10y ago
  That's why we picked fossil over git. The interface is really sane and you can also do stuff from the browser. It gets out of your way. You do not need Python, it can be statically linked easily. It also works on Windows. The usability experience is akin to Mercurial, but even easier to use. Unfortunately it doesn't quie work for bigger projoects (think the Linux kernel or the FreeBSD ports tree) and it can also get slower once you have a lot of history. The repo is esentially a SQLite db.
bsder 10y ago
> Version control is arguably confusing for beginners NO IT IS NOT. <smack to back of head> That kind of thinking is broken. Most people who have been around computers on Windows long enough eventually adopt it. They start creating zip files of directories and they put date codes on them. You laugh, but it works. As such, it's really easy for me to explain Mercurial to them. I simply explain it that Mercurial holds those zip files with some extra information and a pretty GUI. It takes me 30 minutes, max, and they get it. They have one branch. They occasionally share things with other people. And, very occasionally, they have to merge something--which generally gets resolved by taking this file or that file--but rarely actually merging content. Things only start to go bad when you start adding concepts that require the user to keep state of the repository in their head. If the end user has to think about the DAG, yeah, THAT'S complicated. And that's broken. I've now been using git and hg for so long that I know both. I now know enough about git that I have been able to unwedge my teams without just copying the repo (cue xkcd link: https://xkcd.com/1597/ https://xkcd.com/1597/). I don't need to spend hours of Googling anymore, I just need quick reminders of "Oh, yeah, that stupid flag." And, you know what, I have never, ever been in a situation where I thought "Gee, I really wish I was in git rather than Mercurial." The converse, however, happens at least once a week. Perhaps one day my teams or my repos will be complicated enough that the light dawns. The fact that the *BSD guys still operate using CVS and Subversion makes me skeptical.
- skoczymroczny 10y ago
  For me the problems are always merge conflicts. Don't know why, in SVN I wasn't afraid of merge conflicts, I just opened a GUI, clicked on some arrows, picked the parts I want and parts I don't want, save and done. In Git, even with gui tools, I often end up with a mess of .BASE, .LOCAL, .REMOTE files, then I can't merge it all properly, and even if I do it asks me to commit the changes again and it's a mess, so I just clone the repo again and copy the files (xkcd #1597).
  - dasil003 10y ago
    If you think merging in svn is easier than git then you haven't seen the pathological cases of svn merges. The problem is svn has no concept of a repo root or branches, it only has directories, so sooner or later things get very very broken.

by lbotos 10y ago

k__ 10y ago

It's like with IDEs. Eclipse has stuff like workspaces with multiple projects and others have simply projects. What to do with these workspaces? Same goes with Git. Simple VCS have central repositories and a working copy. Git has multiple repositories and every one of them can have a working copy. Other VCS don't have a stage, you simply commit your changes directly into your repository. It's not only that these tools have different commands and stuff like Mercurial or Subversion has easier commands etc. but they really have different concepts that need to be considered while working with these tools on a daily basis. But you don't have to internalize them on your first week or month working with them. When you got your project in the System it's mostly save and if you don't have complex workflows you can still reap the benefits of VCS with Git without knowing everything.

ern 10y ago
I may have misunderstood you, but you do realize that Mercurial is also a DVCS like git, right?

crawfordcomeaux 10y ago

I think there's a difference between learning something that's necessarily complex and learning something with an overly complex design. According to their analysis, the design changes they've made do away with unnecessary complexity.

StavrosK 10y ago

I don't understand this rationale. Are you saying that Git's UI is perfect, and there's no improving it? It's not, and gitless does, indeed, improve on it. We should be celebrating better UIs over important tools, not saying "I made great effort to learn it, therefore learning it with less effort is inferior". No. If it does everything Git does, but more easily, it is strictly superior.

lbotos 10y ago
What I'm saying is, Gitless is cool, BUT beginners are always looking for ways to cheat the effort. My point is, this is a great tool if you understand git, and want to use a shim, but for beginners, going straight to the shim is not good. >If it does everything Git does, but more easily, it is strictly superior. In the abstract I agree, but if an junior dev goes "oh, I just use gitless because it's easier" and DOESN'T understand git, it's a problem. That's my point.
- pjc50 10y ago
  cheat the effort I'm always suspicious of arguments like this, because they have a Luddite quality to them. Isn't sending email versus handwritten postal mail "cheating the effort" of communication? git is a lot of effort to learn because its command line is inconsistent and it is frequently unclear what it has done, why and how to recover from it. It is worth asking if this is really necessary. If a system has a high percentage of beginners pressing the wrong button and losing time and effort as a result, maybe someone should move the buttons?
  - StavrosK 10y ago
    This is spot on, thank you. The git porcelain is very inconsistent between commands, and that really muddies the view of the underlying model. I would argue that a cleaner porcelain would lead to more easily building a mental model of the data structures.
nickpsecurity 10y ago
Well-said. We also know that git was originally hacked together in two weeks after Torvalds had to ditch the better-designed product they were using, Bitkeeper. It's almost as if a bunch of Linux developers kept hacking stuff into it with no concern for UX and telling people they were idiots if they didn't like mastering unnecessary complexity. Meanwhile, unlike Git, I understood most of Gitless's commands before the tutorial started explaining them. Opposite experience I got with Git tutorials where I kept questioning why it would be done a certain, unintuitive way. This is definitely an improvement.

masklinn 10y ago

In my previous job, I taught darcs to a designer/graphics artist. It took about half an hour to go through the CLI, and after that he used it successfully and asked me maybe a pair of questions ever. Now the guy was pretty technical (part of his job was AS development), but he was not a developer. Darcs's and Git's fundamentals are not that different[0], but Darcs's CLI actually makes sense in and of itself independent from the implementation details, and when it diverges from the older standard (e.g. SVN) it's so that commands make more sense, not less. Meanwhile Git has taken pretty much the opposite tack. Git's porcelain is a giant steaming roasted turd sandwich, no other DVCS has such a complex, hostile and nonsensical CLI that people tell you you're supposed to learn it from the storage model up and then it'll make sense. Don't try to shift the buck to VCS/DVCS concepts, while they are complex Git's CLI goes a great way towards making them nonsensical to beginners and non-beginners alike. I routinely used three different DVCS before I had to take the plunge into Git, and it was still a fucking pain in the ass. And that's a problem at every level of resolutions, just compare the hot mess that is gitrevisions(7) to mercurial's (more powerful, more flexible, more readable and more regular) revsets. It's not like revsets are a genius's flash of inspiration either, "hey I'm trying to manipulate sets of revisions, how about I manipulate them as sets?" We're not talking turing award worthy discovery here. [0] well they kinda are, but by and large the fundamental differences are irrelevant to basic day-to-day use.

petre 10y ago
That's why we picked fossil over git. The interface is really sane and you can also do stuff from the browser. It gets out of your way. You do not need Python, it can be statically linked easily. It also works on Windows. The usability experience is akin to Mercurial, but even easier to use. Unfortunately it doesn't quie work for bigger projoects (think the Linux kernel or the FreeBSD ports tree) and it can also get slower once you have a lot of history. The repo is esentially a SQLite db.

bsder 10y ago

> Version control is arguably confusing for beginners NO IT IS NOT. <smack to back of head> That kind of thinking is broken. Most people who have been around computers on Windows long enough eventually adopt it. They start creating zip files of directories and they put date codes on them. You laugh, but it works. As such, it's really easy for me to explain Mercurial to them. I simply explain it that Mercurial holds those zip files with some extra information and a pretty GUI. It takes me 30 minutes, max, and they get it. They have one branch. They occasionally share things with other people. And, very occasionally, they have to merge something--which generally gets resolved by taking this file or that file--but rarely actually merging content. Things only start to go bad when you start adding concepts that require the user to keep state of the repository in their head. If the end user has to think about the DAG, yeah, THAT'S complicated. And that's broken. I've now been using git and hg for so long that I know both. I now know enough about git that I have been able to unwedge my teams without just copying the repo (cue xkcd link: https://xkcd.com/1597/ https://xkcd.com/1597/). I don't need to spend hours of Googling anymore, I just need quick reminders of "Oh, yeah, that stupid flag." And, you know what, I have never, ever been in a situation where I thought "Gee, I really wish I was in git rather than Mercurial." The converse, however, happens at least once a week. Perhaps one day my teams or my repos will be complicated enough that the light dawns. The fact that the *BSD guys still operate using CVS and Subversion makes me skeptical.

skoczymroczny 10y ago
For me the problems are always merge conflicts. Don't know why, in SVN I wasn't afraid of merge conflicts, I just opened a GUI, clicked on some arrows, picked the parts I want and parts I don't want, save and done. In Git, even with gui tools, I often end up with a mess of .BASE, .LOCAL, .REMOTE files, then I can't merge it all properly, and even if I do it asks me to commit the changes again and it's a mess, so I just clone the repo again and copy the files (xkcd #1597).
- dasil003 10y ago
  If you think merging in svn is easier than git then you haven't seen the pathological cases of svn merges. The problem is svn has no concept of a repo root or branches, it only has directories, so sooner or later things get very very broken.