9 ms·

A lot of people simply don't understand why source control isn't a problem solved 100% by tooling in a way that requires little to no interaction at all. To the

A lot of people simply don't understand why source control isn't a problem solved 100% by tooling in a way that requires little to no interaction at all. To them, hearing that they need to read a chapter about the internals of a source control system before working on a project is like hearing they need to understand the details of how a transmission works before they go and drive an automatic - it's inane detail about a workflow they shouldn't even have to deal with because technology has solved the problem, or should have by now. I was on a team that was forced to transition from TFS to git. Among those who weren't excited about it, the majority of the questions, challenges and issues weren't even as far down the road as how to use git, they were mostly along the lines of "why do we have to do all this other stuff now? Today I go to this screen, click this button, my work is now safe and other people can see it." History is linear, full stop, and conflicts are handled by essentially forcing a rebase on commit. Some admin does branching and merging and emails us if there are weird conflicts, we don't worry about that. Why make it more complicated? These folks didn't need git tutorials, they needed to be convinced that curation and management of source history was one of their job responsibilities, which was tough because it really wasn't previously, at least not in any meaningful way.

vidanay 9y ago
Git is the poster child for "leaky abstraction"
- klodolph 9y ago
  I don't think leaky abstraction correctly describes the problem here, because the leaky thing (the fact that history is not linear, and multiple people edit the same files, and that everything is distributed) is not actually an abstraction. In my mind, Git forces you to deal with the fact that history is inherently nonlinear, and then you can choose to create a linear history by the way you use Git. Git's main abstraction is the fact that everything is a content-addressable blob. This "leaks" but it's not a major contributor to the problems people have using Git, at least from what I've seen.
  - masklinn 9y ago
    > In my mind, Git forces you to deal with the fact that history is inherently nonlinear, and then you can choose to create a linear history by the way you use Git. That is not the problem with Git. Mercurial or Darcs also force you to deal with it all the same yet are not anywhere near the UI clusterfuck that Git is. > This "leaks" but it's not a major contributor to the problems people have using Git, at least from what I've seen. It absolutely is, because it leads to commands having unintuitive and incoherent behaviours and thus to the porcelain being impossible to model top-down.
- stouset 9y ago
  I disagree that this is the case. I see it more as git is a DAG, and git's toolchain is simply a set of tools for manipulating the DAG. It's not so much that git is a leaky abstraction as it is that git isn't an abstraction. If you don't know what a DAG is or how commits, files (e.g., blobs), trees, etc. are mapped into the DAG, of course you're going to have a hard time!
  - aero142 9y ago
    I could be able to write the git internals code from memory and it wouldn't help me know what `git checkout` was going to do.
    - stouset 9y ago
      That's almost patently false, since `git checkout` is pretty much just a tool that takes a commit (or a name that points to a commit, like a branch or tag name) and updates the working tree, index, and the HEAD pointer to match the contents of the commit, with some extra safeguards to make sure uncommitted data isn't lost. Three examples (that cover 95%+ of use-cases): $ git checkout some-branch > Updates the index and working tree to reflect the contents of `some-branch`, and updates the HEAD pointer to indicate we're on the `some-branch` branch. $ git checkout -b some-branch > Updates the index and working tree to reflect the contents of `some-branch`, with the "convenience" of creating it first through wrapping `git branch`. This is identical to calling `git branch some-branch; git checkout somebranch`. $ git checkout <optional-commit> -- path/to/a/file > Updates the index and working tree to reflect the contents of the named file on the current or named branch/commit/tag/whatever. TL;DR, `git checkout` has a very clear and well-defined responsibility: update the filesystem and index to reflect the contents of some commit. Various flags and options cause it to perform reasonable variations of this core responsibility (create a branch that doesn't exist first, or update individual files rather than the working tree as a whole). If the commit-name provide is a branch (and you're not checkout out individual files), it also updates the HEAD pointer to point to the named branch, so git "knows what branch you're on". I would be absolutely astonished if you could write the git internals (or even just knew how they worked) and the idea of a tool to make the filesystem look like the internal contents of the repo wasn't immediately apparent. You might not have realized that that's all that `git checkout` does, but once you understand that, it's extremely straightforward.
cortesoft 9y ago
Those people have not worked on large enough teams; we had 50+ committers to an SVN repo before switching to Git, and it was very apparent where the limitations with that 'simple' workflow were.
- Merad 9y ago
  There are a huge number of developers out there who spend the overwhelming majority of their time working solo or on with a couple of peers.
  - matt_the_bass 9y ago
    Sure but for me, even on a solo project git works so much better than svn because I can create multiple branches and easily rebase or merge them as needed. When exploring ideas I might have 3 or 4 possible paths and it’s really nice to have the option of breaking them into different branches until I figure out the right path.
    - Merad 9y ago
      Oh, I agree - but I already know git fairly well. IME those people who have been using TFS solo for a decade have a much harder time seeing the benefits, because they're totally alien to the development workflow that they have become used to.
- to3m 9y ago
  I don't know how many committers have been on the average project I've worked on, but it's probably 25+, and I've worked on several with 50+ - and I don't know how you'd even make Git work at that sort of scale. Obviously people do actually do this, so I assume it must work somehow; I just don't see how it's going to work particularly well. The larger projects I've worked on have typically used Perforce, but I used Alien Brain (which is pretty terrible) for some of the older ones. The check in/check out workflow, which is the same in each case, is basically what makes it all work once you get past a handful of people. Just simply being able to see who else is working on a (almost certainly perfectly cleanly mergeable) file that you're contemplating modifying is a big time-saver. (I've used SVN, at a much smaller scale. It has similar Lock/Unlock functionality, which is a good start, but the performance in general of that seemed to be really bad. Locking a few hundred files might take a full minute, for example. Meanwhile, Perforce will check out 1.9 gazillion files in ten seconds, and that's only because it takes nine seconds to change NTFS permissions for that many files.)
deathanatos 9y ago
I can't speak to your experience on TFS, since I've never used it, but your description of it sounds somewhat similar to Perforce. > History is linear, full stop, and conflicts are handled by essentially forcing a rebase on commit. This is similar to Perforce, but not something I miss. That forced rebase in Perforce has the very real possibility of causing breakages, and there is no way (at least in Perforce) to reliably handle it. I also don't think history should be linear; the cheaper branching model in Git in my experience leads to people actually taking advantage of it; contrast this to Perforce, where branches were expensive: people wouldn't bother. At least in the case of Perforce, the fact people didn't use branches forced them to put all of a feature into a changeset (Perforce's closest equivalent to a commit), which was usually way too much; this results in multiple, distinct changes being squashed together. The lack of cheap branches makes it hard to build a change off of two in-progress changesets, again because the system cannot efficiently represent that state. And then there was just tooling: Git's add -p option for splitting off partial files into a separate commit, the ability to rework the convoluted history that came from my discovery of how best to implement something to something that encapsulates discrete changes that can later be reverted or cherrypicked gracefully (without reverting everything, unless that's really required) are to me, extremely useful tools that just don't exist elsewhere. > Some admin does branching and merging and emails us if there are weird conflicts, we don't worry about that. Why make it more complicated? (To be clear: this does not match my understanding of Perforce; branches there are possible without an admin.) I just simply can't fathom why someone would want to have to go through another human for a branch. It seems like so much bureaucracy for something that, as Git shows, does not require it. > why source control isn't a problem solved 100% by tooling in a way that requires little to no interaction at all. To them, hearing that they need to read a chapter about the internals of a source control system before working on a project I think because, if we accept that history is not linear, and should not be represented as such, then history must therefore be represented as a DAG. A DAG, in my experience, is about the point where people start trying to cheat, for whatever reason, with incompatible and flawed mental models. This bites them in the ass at some point, and they can't understand what they're doing wrong within that flawed mental model, because the model itself is flawed. (And I see this all the time in software engineer, not just with Git. People are too quick to analogize permanently something to something else that is at best a crude approximation.) Now, as another poster in the comments notes, I'd temper with the above with: some of git's tooling and UI could be better. The mix of "index"/"cache"/"staging area" to all mean the same thing, the variety of things "git reset" can do, etc. all are terrible UI on top of a superior model, but do contribute to the confusion newcomers experience. I hope some day this changes.
jogjayr 9y ago
> is like hearing they need to understand the details of how a transmission works before they go and drive an automatic Which would be a reasonable attitude for your average driver but not for a professional mechanical or automotive engineer.
- uryga 9y ago
  Why? Unless I'm misunderstanding, you seem to be saying that being a programmer implies having a desire to understand every program's internals. But I don't care how Photoshop stores the 30-layer document I'm editing, and I feel like I shouldn't have to. I can't see why Git should be treated differently.
  - stochastastic 9y ago
    I think the argument would be that you need to understand what those 30 layers in Photoshop represent and how they interact with each other, not how they are stored.
  - a_tractor 9y ago
    >why Git should be treated differently well for starters, git is free, while Photoshop is made by a for-profit corporation that has always charged quite a lot of money for it. >a desire to understand every program's internals You don't need to know its "internals," but you should understand how it works. That is not a lot to ask. Just like with Photoshop you need to know how to use the lasso tool, how layer masking works, how the difference color tools can be used, how to change image sizes and the limits of what you would want to do, how to preserve source images and work as lossless as possible, or 1 or 2 of the 5 different ways that you can accomplish a specific task with the program, etc, etc... to use git you need to know what its commands do. Photoshop is more equivalent to an IDE, which is usually paid for and usually comes with robust tools for managing a VCS like git, anyway. >how Photoshop stores the 30-layer document Yeah, and a lot of terrible designers don't care enough about the benefits of working with layers to bother with that either. No, you care about the opportunity for a massively improved workflow efficiency, so you bothered to figure it out. That is the equivalence with Git. >being a programmer implies having a desire to understand what does being a programmer imply, then? Anyway, starting from 0 familiarity, Git is just as easy to start using as Photoshop, and both can be just as complicated as you need it to be.
stouset 9y ago
> A lot of people simply don't understand why source control isn't a problem solved 100% by tooling in a way that requires little to no interaction at all. This is true of basically all problem domains: "Why isn't X easy? Can't you just do Y?" And it usually just indicates that the person asking the question doesn't appreciate how difficult and nuanced a real solution to X is. Real-world problems are often difficult and have non-obvious, sometimes-intractable challenges. "Easy" solutions often cause more problems than they solve — there's a reason why more complicated tools like git have taken over from less-capable tools like Subversion and CVS.
- nikofeyn 9y ago
  that can happen, but it can also serve as an excuse. in git, for example, why can’t i switch branches with uncommitted changes? it makes no sense why i can’t do that, but yet, there it is. > there’s a reason why more complicated tools like git have taken over from less-capable tools like Subversion and CVS. i don’t think the reasons have much to do with usability or even capability. i came to git from perforce, where the latter was much easier to use, reason about, fix issues, and has much better tooling, in particular visual tools. it’s also amazing how slow git is.
  - stouset 9y ago
    > in git, for example, why can’t i switch branches with uncommitted changes? it makes no sense why i can’t do that, but yet, there it is. Except you can? [stouset:~/Development/some-project] some-branch(+8/-4)+ $ git status On branch some-branch Your branch is up to date with 'origin/some-branch'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: path/to/file1 modified: path/to/file2 no changes added to commit (use "git add" and/or "git commit -a") [stouset:~/Development/some-project] some-branch(+8/-4)+ $ git checkout master M path/to/file1 M path/to/file2 Switched to branch 'master' Your branch is up to date with 'origin/master'. > i don’t think the reasons have much to do with usability or even capability. i came to git from perforce, where the latter was much easier to use, reason about, fix issues, and has much better tooling, in particular visual tools. it’s also amazing how slow git is. Perforce isn't free. git's popular predecessors were. That said, I've found in my experience that way more people seem to hate Perforce than seem to hate git.
GiorgioG 9y ago
Similar experience here - I had a team of developers who had to move off of an internal TFS server to Bitbucket / git. I gave them all of the reference/doc links, gave them a brief overview about how git in fundamentally different than a centralized VCS. At the end of several sessions w/git (using git bash on Windows), their comment to me was: "But we're using to clicking on buttons in Visual Studio"
- flukus 9y ago
  The problem is even deeper than that, with a lot of IDE developers and particularly Visual Studio ones there entire world is in the IDE, anything outside of it may as well not exist, anything the IDE can't do is impossible. Many wouldn't even be able to compile there own projects if you took the IDE away. An email I got the other day was "we can't debug problem with x because it's built on the CI server" and the problem was in the first few milliseconds of startup so "attach to process" was no good, even if they knew that was possible. The idea of using a debugger outside of the IDE (mdbg in this case) never crossed their mind. IDE's a great for coding, but too many devs are way to reliant on them.
  - seanmcdirmid 9y ago
    Why shouldn’t they be? Why should compiling a file or debugging a project require so much command line hackery? Why can’t IDEs actually do what they promised (integrate dev tools and make them more usable)? It is so weird that in the 90s I could do MORE in my IDE than I can today, somehow our tools have trended to increasing complexity while IDE advancement has come almost to a stand still, with a preference to simpler less integrated ones (e.g. VS Code).
    - dotancohen 9y ago
      I used to feel the same way, especially as a VIM user. Why is every IDE worse than VIM, and why do I have to learn a new IDE for Python, C++, PHP, and Java? Enter the Jetbrains IDE. The same basic program for almost every programming language and a terrific VIM plugin to boot. It's on the order of $100 per year. Well worth the cost, and the only non-FOSS code on my computer other than the MP3 codecs. I usually don't use the built-in Git commands in PyCharm, but I do use the built-in terminal to perform Git operations. The only Git work I do with the IDE directly is resolve merge conflicts, because that specific tool is terrific.
matt_the_bass 9y ago
This is the crux: > they needed to be convinced that curation and management of source history was one of their job responsibilities, which was tough because it really wasn't previously, at least not in any meaningful way. Getting people to be responsible for the whole is hard.
andrewla 9y ago
> ... hearing they need to understand the details of how a transmission works before they go and drive an automatic I feel like a much better metaphor is the difference between understanding that turning the steering wheel turns the car and understanding that turning the steering wheel turns the front wheels. You can drive a car without knowing that, but at some point you will find that not knowing that prevents you from having an intuitive grasp of things like parallel parking. In software engineering, an even more apt analogy is understanding how compilers/interpreters work. You can do a lot of programming treating those as black boxes that make your program run, but eventually you have to have the deeper understanding.
- rz2k 9y ago
  Interestingly, it is really difficult to explain how the rudder doesn’t just change the boat’s direction when teaching sailing. It especially happens after a student has just begun to understand that they can only move in some directions relative to the wind, and they feel stuck with the boat pointed straight into the wind. You have to move to change your heading, and you have to change your heading to move? The first reaction is to feel like the rudder is broken.
  - NegativeLatency 9y ago
    If the boat is small enough you can just rudder pump your way out of that one though. :)
    - bennyelv 9y ago
      If you're racing then you need to make sure you only pump in one direction (called sculling - in this case ) or you'll fall foul of rule 42: http://www.sailing.org/tools/documents/42Interpretationsforbooklet-[15296].pdf http://www.sailing.org/tools/documents/42Interpretationsforb...
    - rz2k 9y ago
      Additionally, being "stuck" pointing straight into the wind isn't a situation where you are stuck with zero velocity indefinitely. The wind is forcing you backwards, and the arrangement of the rudder and keel/centerboard is unstable for going backwards without changing direction. Even if you don't know what you are doing you'll generally point one way or the other enough that you can then fill your sails again and have more normal control. Ways to make this faster include pushing the main sail on a small boat out to the "wrong" side, tightening the front sail on the "wrong" side of a larger boat, and positioning the rudder only a little off center so that the slowly moving water relative to the boat is less turbulent. Probably the only time when it is an actual problem is when people are drifting into some obstacle. It seemed to take students a matter of seconds to regain control of their boat when they were surrounded by large expanses of water. When they were frantic, their intuition about what they needed to do when in a hurry prolonged their loss of control.
u801e 9y ago
> To them, hearing that they need to read a chapter about the internals of a source control system before working on a project is like hearing they need to understand the details of how a transmission works before they go and drive an automatic Shouldn't a mechanic have an understanding of how an automatic transmission works? Similarly, shouldn't a software developer have an understanding of how version control works? In general, a professional should have a very good understanding of the tools they use for their work as well as what they're working on.
sjellis 9y ago
"These folks didn't need git tutorials, they needed to be convinced that curation and management of source history was one of their job responsibilities, which was tough because it really wasn't previously, at least not in any meaningful way." I've had a very similar experience. IMO, your source control is an essential working tool, like your text editor, and you should be very proficient with it, but plenty of developers that I've met don't share that view.

vidanay 9y ago

Git is the poster child for "leaky abstraction"

klodolph 9y ago
I don't think leaky abstraction correctly describes the problem here, because the leaky thing (the fact that history is not linear, and multiple people edit the same files, and that everything is distributed) is not actually an abstraction. In my mind, Git forces you to deal with the fact that history is inherently nonlinear, and then you can choose to create a linear history by the way you use Git. Git's main abstraction is the fact that everything is a content-addressable blob. This "leaks" but it's not a major contributor to the problems people have using Git, at least from what I've seen.
- masklinn 9y ago
  > In my mind, Git forces you to deal with the fact that history is inherently nonlinear, and then you can choose to create a linear history by the way you use Git. That is not the problem with Git. Mercurial or Darcs also force you to deal with it all the same yet are not anywhere near the UI clusterfuck that Git is. > This "leaks" but it's not a major contributor to the problems people have using Git, at least from what I've seen. It absolutely is, because it leads to commands having unintuitive and incoherent behaviours and thus to the porcelain being impossible to model top-down.
stouset 9y ago
I disagree that this is the case. I see it more as git is a DAG, and git's toolchain is simply a set of tools for manipulating the DAG. It's not so much that git is a leaky abstraction as it is that git isn't an abstraction. If you don't know what a DAG is or how commits, files (e.g., blobs), trees, etc. are mapped into the DAG, of course you're going to have a hard time!
- aero142 9y ago
  I could be able to write the git internals code from memory and it wouldn't help me know what `git checkout` was going to do.
  - stouset 9y ago
    That's almost patently false, since `git checkout` is pretty much just a tool that takes a commit (or a name that points to a commit, like a branch or tag name) and updates the working tree, index, and the HEAD pointer to match the contents of the commit, with some extra safeguards to make sure uncommitted data isn't lost. Three examples (that cover 95%+ of use-cases): $ git checkout some-branch > Updates the index and working tree to reflect the contents of `some-branch`, and updates the HEAD pointer to indicate we're on the `some-branch` branch. $ git checkout -b some-branch > Updates the index and working tree to reflect the contents of `some-branch`, with the "convenience" of creating it first through wrapping `git branch`. This is identical to calling `git branch some-branch; git checkout somebranch`. $ git checkout <optional-commit> -- path/to/a/file > Updates the index and working tree to reflect the contents of the named file on the current or named branch/commit/tag/whatever. TL;DR, `git checkout` has a very clear and well-defined responsibility: update the filesystem and index to reflect the contents of some commit. Various flags and options cause it to perform reasonable variations of this core responsibility (create a branch that doesn't exist first, or update individual files rather than the working tree as a whole). If the commit-name provide is a branch (and you're not checkout out individual files), it also updates the HEAD pointer to point to the named branch, so git "knows what branch you're on". I would be absolutely astonished if you could write the git internals (or even just knew how they worked) and the idea of a tool to make the filesystem look like the internal contents of the repo wasn't immediately apparent. You might not have realized that that's all that `git checkout` does, but once you understand that, it's extremely straightforward.

cortesoft 9y ago

Those people have not worked on large enough teams; we had 50+ committers to an SVN repo before switching to Git, and it was very apparent where the limitations with that 'simple' workflow were.

Merad 9y ago
There are a huge number of developers out there who spend the overwhelming majority of their time working solo or on with a couple of peers.
- matt_the_bass 9y ago
  Sure but for me, even on a solo project git works so much better than svn because I can create multiple branches and easily rebase or merge them as needed. When exploring ideas I might have 3 or 4 possible paths and it’s really nice to have the option of breaking them into different branches until I figure out the right path.
  - Merad 9y ago
    Oh, I agree - but I already know git fairly well. IME those people who have been using TFS solo for a decade have a much harder time seeing the benefits, because they're totally alien to the development workflow that they have become used to.
to3m 9y ago
I don't know how many committers have been on the average project I've worked on, but it's probably 25+, and I've worked on several with 50+ - and I don't know how you'd even make Git work at that sort of scale. Obviously people do actually do this, so I assume it must work somehow; I just don't see how it's going to work particularly well. The larger projects I've worked on have typically used Perforce, but I used Alien Brain (which is pretty terrible) for some of the older ones. The check in/check out workflow, which is the same in each case, is basically what makes it all work once you get past a handful of people. Just simply being able to see who else is working on a (almost certainly perfectly cleanly mergeable) file that you're contemplating modifying is a big time-saver. (I've used SVN, at a much smaller scale. It has similar Lock/Unlock functionality, which is a good start, but the performance in general of that seemed to be really bad. Locking a few hundred files might take a full minute, for example. Meanwhile, Perforce will check out 1.9 gazillion files in ten seconds, and that's only because it takes nine seconds to change NTFS permissions for that many files.)

deathanatos 9y ago

I can't speak to your experience on TFS, since I've never used it, but your description of it sounds somewhat similar to Perforce. > History is linear, full stop, and conflicts are handled by essentially forcing a rebase on commit. This is similar to Perforce, but not something I miss. That forced rebase in Perforce has the very real possibility of causing breakages, and there is no way (at least in Perforce) to reliably handle it. I also don't think history should be linear; the cheaper branching model in Git in my experience leads to people actually taking advantage of it; contrast this to Perforce, where branches were expensive: people wouldn't bother. At least in the case of Perforce, the fact people didn't use branches forced them to put all of a feature into a changeset (Perforce's closest equivalent to a commit), which was usually way too much; this results in multiple, distinct changes being squashed together. The lack of cheap branches makes it hard to build a change off of two in-progress changesets, again because the system cannot efficiently represent that state. And then there was just tooling: Git's add -p option for splitting off partial files into a separate commit, the ability to rework the convoluted history that came from my discovery of how best to implement something to something that encapsulates discrete changes that can later be reverted or cherrypicked gracefully (without reverting everything, unless that's really required) are to me, extremely useful tools that just don't exist elsewhere. > Some admin does branching and merging and emails us if there are weird conflicts, we don't worry about that. Why make it more complicated? (To be clear: this does not match my understanding of Perforce; branches there are possible without an admin.) I just simply can't fathom why someone would want to have to go through another human for a branch. It seems like so much bureaucracy for something that, as Git shows, does not require it. > why source control isn't a problem solved 100% by tooling in a way that requires little to no interaction at all. To them, hearing that they need to read a chapter about the internals of a source control system before working on a project I think because, if we accept that history is not linear, and should not be represented as such, then history must therefore be represented as a DAG. A DAG, in my experience, is about the point where people start trying to cheat, for whatever reason, with incompatible and flawed mental models. This bites them in the ass at some point, and they can't understand what they're doing wrong within that flawed mental model, because the model itself is flawed. (And I see this all the time in software engineer, not just with Git. People are too quick to analogize permanently something to something else that is at best a crude approximation.) Now, as another poster in the comments notes, I'd temper with the above with: some of git's tooling and UI could be better. The mix of "index"/"cache"/"staging area" to all mean the same thing, the variety of things "git reset" can do, etc. all are terrible UI on top of a superior model, but do contribute to the confusion newcomers experience. I hope some day this changes.

jogjayr 9y ago

> is like hearing they need to understand the details of how a transmission works before they go and drive an automatic Which would be a reasonable attitude for your average driver but not for a professional mechanical or automotive engineer.

uryga 9y ago
Why? Unless I'm misunderstanding, you seem to be saying that being a programmer implies having a desire to understand every program's internals. But I don't care how Photoshop stores the 30-layer document I'm editing, and I feel like I shouldn't have to. I can't see why Git should be treated differently.
- stochastastic 9y ago
  I think the argument would be that you need to understand what those 30 layers in Photoshop represent and how they interact with each other, not how they are stored.
- a_tractor 9y ago
  >why Git should be treated differently well for starters, git is free, while Photoshop is made by a for-profit corporation that has always charged quite a lot of money for it. >a desire to understand every program's internals You don't need to know its "internals," but you should understand how it works. That is not a lot to ask. Just like with Photoshop you need to know how to use the lasso tool, how layer masking works, how the difference color tools can be used, how to change image sizes and the limits of what you would want to do, how to preserve source images and work as lossless as possible, or 1 or 2 of the 5 different ways that you can accomplish a specific task with the program, etc, etc... to use git you need to know what its commands do. Photoshop is more equivalent to an IDE, which is usually paid for and usually comes with robust tools for managing a VCS like git, anyway. >how Photoshop stores the 30-layer document Yeah, and a lot of terrible designers don't care enough about the benefits of working with layers to bother with that either. No, you care about the opportunity for a massively improved workflow efficiency, so you bothered to figure it out. That is the equivalence with Git. >being a programmer implies having a desire to understand what does being a programmer imply, then? Anyway, starting from 0 familiarity, Git is just as easy to start using as Photoshop, and both can be just as complicated as you need it to be.

stouset 9y ago

> A lot of people simply don't understand why source control isn't a problem solved 100% by tooling in a way that requires little to no interaction at all. This is true of basically all problem domains: "Why isn't X easy? Can't you just do Y?" And it usually just indicates that the person asking the question doesn't appreciate how difficult and nuanced a real solution to X is. Real-world problems are often difficult and have non-obvious, sometimes-intractable challenges. "Easy" solutions often cause more problems than they solve — there's a reason why more complicated tools like git have taken over from less-capable tools like Subversion and CVS.

nikofeyn 9y ago
that can happen, but it can also serve as an excuse. in git, for example, why can’t i switch branches with uncommitted changes? it makes no sense why i can’t do that, but yet, there it is. > there’s a reason why more complicated tools like git have taken over from less-capable tools like Subversion and CVS. i don’t think the reasons have much to do with usability or even capability. i came to git from perforce, where the latter was much easier to use, reason about, fix issues, and has much better tooling, in particular visual tools. it’s also amazing how slow git is.
- stouset 9y ago
  > in git, for example, why can’t i switch branches with uncommitted changes? it makes no sense why i can’t do that, but yet, there it is. Except you can? [stouset:~/Development/some-project] some-branch(+8/-4)+ $ git status On branch some-branch Your branch is up to date with 'origin/some-branch'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: path/to/file1 modified: path/to/file2 no changes added to commit (use "git add" and/or "git commit -a") [stouset:~/Development/some-project] some-branch(+8/-4)+ $ git checkout master M path/to/file1 M path/to/file2 Switched to branch 'master' Your branch is up to date with 'origin/master'. > i don’t think the reasons have much to do with usability or even capability. i came to git from perforce, where the latter was much easier to use, reason about, fix issues, and has much better tooling, in particular visual tools. it’s also amazing how slow git is. Perforce isn't free. git's popular predecessors were. That said, I've found in my experience that way more people seem to hate Perforce than seem to hate git.

GiorgioG 9y ago

Similar experience here - I had a team of developers who had to move off of an internal TFS server to Bitbucket / git. I gave them all of the reference/doc links, gave them a brief overview about how git in fundamentally different than a centralized VCS. At the end of several sessions w/git (using git bash on Windows), their comment to me was: "But we're using to clicking on buttons in Visual Studio"

flukus 9y ago
The problem is even deeper than that, with a lot of IDE developers and particularly Visual Studio ones there entire world is in the IDE, anything outside of it may as well not exist, anything the IDE can't do is impossible. Many wouldn't even be able to compile there own projects if you took the IDE away. An email I got the other day was "we can't debug problem with x because it's built on the CI server" and the problem was in the first few milliseconds of startup so "attach to process" was no good, even if they knew that was possible. The idea of using a debugger outside of the IDE (mdbg in this case) never crossed their mind. IDE's a great for coding, but too many devs are way to reliant on them.
- seanmcdirmid 9y ago
  Why shouldn’t they be? Why should compiling a file or debugging a project require so much command line hackery? Why can’t IDEs actually do what they promised (integrate dev tools and make them more usable)? It is so weird that in the 90s I could do MORE in my IDE than I can today, somehow our tools have trended to increasing complexity while IDE advancement has come almost to a stand still, with a preference to simpler less integrated ones (e.g. VS Code).
  - dotancohen 9y ago
    I used to feel the same way, especially as a VIM user. Why is every IDE worse than VIM, and why do I have to learn a new IDE for Python, C++, PHP, and Java? Enter the Jetbrains IDE. The same basic program for almost every programming language and a terrific VIM plugin to boot. It's on the order of $100 per year. Well worth the cost, and the only non-FOSS code on my computer other than the MP3 codecs. I usually don't use the built-in Git commands in PyCharm, but I do use the built-in terminal to perform Git operations. The only Git work I do with the IDE directly is resolve merge conflicts, because that specific tool is terrific.

matt_the_bass 9y ago

This is the crux: > they needed to be convinced that curation and management of source history was one of their job responsibilities, which was tough because it really wasn't previously, at least not in any meaningful way. Getting people to be responsible for the whole is hard.

andrewla 9y ago

> ... hearing they need to understand the details of how a transmission works before they go and drive an automatic I feel like a much better metaphor is the difference between understanding that turning the steering wheel turns the car and understanding that turning the steering wheel turns the front wheels. You can drive a car without knowing that, but at some point you will find that not knowing that prevents you from having an intuitive grasp of things like parallel parking. In software engineering, an even more apt analogy is understanding how compilers/interpreters work. You can do a lot of programming treating those as black boxes that make your program run, but eventually you have to have the deeper understanding.

rz2k 9y ago
Interestingly, it is really difficult to explain how the rudder doesn’t just change the boat’s direction when teaching sailing. It especially happens after a student has just begun to understand that they can only move in some directions relative to the wind, and they feel stuck with the boat pointed straight into the wind. You have to move to change your heading, and you have to change your heading to move? The first reaction is to feel like the rudder is broken.
- NegativeLatency 9y ago
  If the boat is small enough you can just rudder pump your way out of that one though. :)
  - bennyelv 9y ago
    If you're racing then you need to make sure you only pump in one direction (called sculling - in this case ) or you'll fall foul of rule 42: http://www.sailing.org/tools/documents/42Interpretationsforbooklet-[15296].pdf http://www.sailing.org/tools/documents/42Interpretationsforb...
  - rz2k 9y ago
    Additionally, being "stuck" pointing straight into the wind isn't a situation where you are stuck with zero velocity indefinitely. The wind is forcing you backwards, and the arrangement of the rudder and keel/centerboard is unstable for going backwards without changing direction. Even if you don't know what you are doing you'll generally point one way or the other enough that you can then fill your sails again and have more normal control. Ways to make this faster include pushing the main sail on a small boat out to the "wrong" side, tightening the front sail on the "wrong" side of a larger boat, and positioning the rudder only a little off center so that the slowly moving water relative to the boat is less turbulent. Probably the only time when it is an actual problem is when people are drifting into some obstacle. It seemed to take students a matter of seconds to regain control of their boat when they were surrounded by large expanses of water. When they were frantic, their intuition about what they needed to do when in a hurry prolonged their loss of control.

u801e 9y ago

> To them, hearing that they need to read a chapter about the internals of a source control system before working on a project is like hearing they need to understand the details of how a transmission works before they go and drive an automatic Shouldn't a mechanic have an understanding of how an automatic transmission works? Similarly, shouldn't a software developer have an understanding of how version control works? In general, a professional should have a very good understanding of the tools they use for their work as well as what they're working on.

sjellis 9y ago

"These folks didn't need git tutorials, they needed to be convinced that curation and management of source history was one of their job responsibilities, which was tough because it really wasn't previously, at least not in any meaningful way." I've had a very similar experience. IMO, your source control is an essential working tool, like your text editor, and you should be very proficient with it, but plenty of developers that I've met don't share that view.