And here, perfectly illustrated, is a reminder why I don't like using some source code version control systems. I don't want to understand the precise implementation of my source code control system, and I don't personally believe that I should have to for effective use.
I realise this is likely an unpopular opinion, but I would challenge you to reply with justification rather than inevitably downvoting me into oblivion.
One of my software development mentors (a long time mechanical engineer who has done UNIX OS development for 20+ years) often has this as his email signature and I think it's rather apt in this context:
Civilization advances by extending the number of
important operations which we can perform without
thinking about them.
With that said, I'm not advocating complete ignorance of how a version control system "works", I just find the philosophy of "you must learn the internal data formats and workings of this system to use it effectively" more than a bit distasteful.
You might very well be right. It might be a fundamental flaw of Git that in order to use it, you have to understand its innards. Certainly, in order to use it effectively, and in order to avoid disaster, you need to now how it's storing data.
I've never used it, but I've heard that Mercurial offers most of the power of Git, with much less of the pain, and an easier user interface. I'm willing to believe that this is true. I'll even believe (whether it's true or not) that Mercurial does provide a nice abstraction layer, one that allows you to ignore the underlying implementation.
The thing is, that doesn't matter at this point. Many people (including me) have gotten through the Git learning curve and now find it to be fantastically useful. I'm far more productive with Git than I was with SVN or CVS, and I'm not the only one to feel this way. As a result, you now have an ecosystem of tools, tutorials, books, etc. that all build on Git -- not to mention companies such as GitHub and GitLab that supply (relatively) easy-to-use tools and interfaces.
Also: A large part of Git's power stems from the fact that you're always thinking in terms of commits, and where those commits fit on your repository's graph. I'm not sure how you can abstract away from that, even if it's an interesting idea in theory.
A combination of critical mass (among open-source developers and a growing number of corporations), an ecosystem, and a powerful (if hard to understand) data model has made Git the standard nowadays. It's a crying shame that Git is so hard for so many people to get... but I've found that in my own work, the learning curve was more than worthwhile, and has made me more productive.
It might be a fundamental flaw of Git that in order to use it, you have to understand its innards. Certainly, in order to use it effectively, and in order to avoid disaster, you need to now how it's storing data.
I've been using git for 5 years now, and I don't have a clear understanding of "its innards". I once read an overview of how it works under the hood and have a vague notion of what's going on.
What are the typical use case scenarios where you need to know implementation details to "avoid disaster"?
I can rebase/merge/push/pull/commit just fine while being ignorant of implementation.
Just how does using `git init`, `git add`, `git commit`, `git push`, `git merge`, `git pull` force one to know Git's implementation details?
Even thinking of Git as a security camera watching your shop (working tree), a VCR (record, forward, rewind history), a videotape copier (branching, pushing) and video editor (pulling, merging) wouldn't be too far off the mark, without the need for any reference to Git's inner workings.
Sure, a lot of Git talk mentions SHAs, trees, blobs, etc., but they could just as well have been brownies, blurfls, gizmos or whatever, as long as the practical context in which one needs these things is clear. Branches, tags and remotes are still the most useful top-level concepts, with no need for knowing their implementation details.
Only when one needs to do really low-level stuff like efficient import/export, history rewriting (ugh) etc. does one need to know a little more about how Git works. Many people have used Git for years without knowing anything about the plumbing beneath its porcelain.
That's why I said it was a "reminder" and not a perfect illustration. Almost every article and bit of material I read on Git advocates the understanding of its data formats to make "effective" use of Git or claims that once you understand those things then you can understand how to use the system.
Even then, I personally find Git's interface confusing and inconsistent -- there are various examples of that with how you request help (usage) for various commands.
The only way I can personally tolerate using Git at the moment is via SourceTree or the GitHub web interface.
That's just my personal opinion of course and isn't necessarily a factual reflection of Git itself.
I've used various source code control systems over the years: sccs, perforce, bitkeeper, cvs, svn, bzr, mercurial, and so on to various degrees if that means anything. The one I've finally settled on for personal use has been mercurial, which I've generally found fits my own workflows the best and generally has an interface that seems to work without me having to think about it too much.
Almost every article and bit of material I read on Git advocates the understanding of its data formats to make "effective" use of Git or claims that once you understand those things then you can understand how to use the system.
This perspective has root in Fred Brook's observation "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."
With that usage, you don't need to understand the implementation. But in my experience of using Git without really understanding it, there is about a 90% chance of destroying your repository when you try to revert something. I have never had this problem with any other VCS.
I'm sure simple reverting is super easy once you know what you're doing, but you need to know what you're doing.
Well that does look simple, but first of all, it doesn't really revert a commit. It makes a new commit to cancel out the old one, or something. Not intuitive, unexpected results if you don't know what you're doing.
But the situation I got into was when I did something stupid and just wanted to undo it. Let me go back to an hour ago before I screwed up my project. That's not revert, it's reset, but reset only reverts the commit history, you really want reset --hard. And of course you need to be pointing to the right place for this to work, and there are other ways for it to go wrong. It might be hard to imagine if you're at all competent with Git, but trust me when I say you can get yourself into some very frustrating scenarios if you just Google "undo push" and blindly follow the instructions.
Here's another simple scenario: I'm working on a bug, my friend fixes it first and pushes his version. I just want to pull his changes and throw away whatever I was working on. Ok, so I find this: http://stackoverflow.com/questions/1125968/force-git-to-over...
Look how many different methods there are. Look how many warnings of "THIS WILL DELETE ALL UNTRACKED FILES" there are. Why is this necessary? I could rant for a while longer, but this stuff is so incredibly unfriendly and frustrating to newcomers. I don't want to think about this stuff, I just want to go back to the code.
And yet every time I looked at the docs for git in the two or three years I was using it heavily I happened upon these dire warnings about destroying and losing work. I understand why git is so powerful, and to manage something as complex as the Linux kernel that power matters.
For what I do for a living it isn't, and Mercurial is a nice alternative that for whatever reason doesn't have any scary warnings in the docs about how I can destroy everything if I revert or rebase inappropriately, or whatever. Mercurial also seems a lot more aggressive about checking if I'm doing something stupid or dangerous and warning me about it, whereas git takes more of the traditional Unix "You Asked For It You Got It" philosophy.
Again: I understand why this is the case, but it's not the optimal tradeoff for me.
I think calling the basics of the data model its 'precise implementation' is excessive. It's like complaining about having to learn the precise details of your display server because someone tries to explain to you how windows in a typical window manager work. The underlying model of git is not terribly complicated, is distinct from (but maps reasonably closely to) its implementation, and it makes understanding all the operations on a repo and working directory a lot easier, as well as making it easier to google for help if you get stuck or want to do something new.
Git hides a lot of complexity, instead exposing an unintuitive set of commands to control your data. Multi-user distributed version control is a very complicated problem to which there will never be a simple solution. If you are willing to sacrifice some features, there are probably simpler solutions that would be more fitting with your work process.
I agree. Everyone should do their own cost benefit analysis. Git has a set of features and costs that make it highly suitable for some combinations of organization and project and not so suited for other combinations. There is no silver bullet.
Comments
And here, perfectly illustrated, is a reminder why I don't like using some source code version control systems. I don't want to understand the precise implementation of my source code control system, and I don't personally believe that I should have to for effective use.
I realise this is likely an unpopular opinion, but I would challenge you to reply with justification rather than inevitably downvoting me into oblivion.
One of my software development mentors (a long time mechanical engineer who has done UNIX OS development for 20+ years) often has this as his email signature and I think it's rather apt in this context:
With that said, I'm not advocating complete ignorance of how a version control system "works", I just find the philosophy of "you must learn the internal data formats and workings of this system to use it effectively" more than a bit distasteful.You might very well be right. It might be a fundamental flaw of Git that in order to use it, you have to understand its innards. Certainly, in order to use it effectively, and in order to avoid disaster, you need to now how it's storing data.
I've never used it, but I've heard that Mercurial offers most of the power of Git, with much less of the pain, and an easier user interface. I'm willing to believe that this is true. I'll even believe (whether it's true or not) that Mercurial does provide a nice abstraction layer, one that allows you to ignore the underlying implementation.
The thing is, that doesn't matter at this point. Many people (including me) have gotten through the Git learning curve and now find it to be fantastically useful. I'm far more productive with Git than I was with SVN or CVS, and I'm not the only one to feel this way. As a result, you now have an ecosystem of tools, tutorials, books, etc. that all build on Git -- not to mention companies such as GitHub and GitLab that supply (relatively) easy-to-use tools and interfaces.
Also: A large part of Git's power stems from the fact that you're always thinking in terms of commits, and where those commits fit on your repository's graph. I'm not sure how you can abstract away from that, even if it's an interesting idea in theory.
A combination of critical mass (among open-source developers and a growing number of corporations), an ecosystem, and a powerful (if hard to understand) data model has made Git the standard nowadays. It's a crying shame that Git is so hard for so many people to get... but I've found that in my own work, the learning curve was more than worthwhile, and has made me more productive.
I've been using git for 5 years now, and I don't have a clear understanding of "its innards". I once read an overview of how it works under the hood and have a vague notion of what's going on.
What are the typical use case scenarios where you need to know implementation details to "avoid disaster"?
I can rebase/merge/push/pull/commit just fine while being ignorant of implementation.
This is surprisingly straight-forward: http://eagain.net/articles/git-for-computer-scientists/
Just how does using `git init`, `git add`, `git commit`, `git push`, `git merge`, `git pull` force one to know Git's implementation details?
Even thinking of Git as a security camera watching your shop (working tree), a VCR (record, forward, rewind history), a videotape copier (branching, pushing) and video editor (pulling, merging) wouldn't be too far off the mark, without the need for any reference to Git's inner workings.
Sure, a lot of Git talk mentions SHAs, trees, blobs, etc., but they could just as well have been brownies, blurfls, gizmos or whatever, as long as the practical context in which one needs these things is clear. Branches, tags and remotes are still the most useful top-level concepts, with no need for knowing their implementation details.
Only when one needs to do really low-level stuff like efficient import/export, history rewriting (ugh) etc. does one need to know a little more about how Git works. Many people have used Git for years without knowing anything about the plumbing beneath its porcelain.
That's why I said it was a "reminder" and not a perfect illustration. Almost every article and bit of material I read on Git advocates the understanding of its data formats to make "effective" use of Git or claims that once you understand those things then you can understand how to use the system.
Even then, I personally find Git's interface confusing and inconsistent -- there are various examples of that with how you request help (usage) for various commands.
The only way I can personally tolerate using Git at the moment is via SourceTree or the GitHub web interface.
That's just my personal opinion of course and isn't necessarily a factual reflection of Git itself.
I've used various source code control systems over the years: sccs, perforce, bitkeeper, cvs, svn, bzr, mercurial, and so on to various degrees if that means anything. The one I've finally settled on for personal use has been mercurial, which I've generally found fits my own workflows the best and generally has an interface that seems to work without me having to think about it too much.
Almost every article and bit of material I read on Git advocates the understanding of its data formats to make "effective" use of Git or claims that once you understand those things then you can understand how to use the system.
This perspective has root in Fred Brook's observation "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."
With that usage, you don't need to understand the implementation. But in my experience of using Git without really understanding it, there is about a 90% chance of destroying your repository when you try to revert something. I have never had this problem with any other VCS.
I'm sure simple reverting is super easy once you know what you're doing, but you need to know what you're doing.
Reverting a commit is trivial. There is zero opportunity of destroying a repo. From my notes,
# revert a commit
git revert dd61ab32
Well that does look simple, but first of all, it doesn't really revert a commit. It makes a new commit to cancel out the old one, or something. Not intuitive, unexpected results if you don't know what you're doing.
But the situation I got into was when I did something stupid and just wanted to undo it. Let me go back to an hour ago before I screwed up my project. That's not revert, it's reset, but reset only reverts the commit history, you really want reset --hard. And of course you need to be pointing to the right place for this to work, and there are other ways for it to go wrong. It might be hard to imagine if you're at all competent with Git, but trust me when I say you can get yourself into some very frustrating scenarios if you just Google "undo push" and blindly follow the instructions.
Here's another simple scenario: I'm working on a bug, my friend fixes it first and pushes his version. I just want to pull his changes and throw away whatever I was working on. Ok, so I find this: http://stackoverflow.com/questions/1125968/force-git-to-over...
Look how many different methods there are. Look how many warnings of "THIS WILL DELETE ALL UNTRACKED FILES" there are. Why is this necessary? I could rant for a while longer, but this stuff is so incredibly unfriendly and frustrating to newcomers. I don't want to think about this stuff, I just want to go back to the code.
And yet every time I looked at the docs for git in the two or three years I was using it heavily I happened upon these dire warnings about destroying and losing work. I understand why git is so powerful, and to manage something as complex as the Linux kernel that power matters.
For what I do for a living it isn't, and Mercurial is a nice alternative that for whatever reason doesn't have any scary warnings in the docs about how I can destroy everything if I revert or rebase inappropriately, or whatever. Mercurial also seems a lot more aggressive about checking if I'm doing something stupid or dangerous and warning me about it, whereas git takes more of the traditional Unix "You Asked For It You Got It" philosophy.
Again: I understand why this is the case, but it's not the optimal tradeoff for me.
I think calling the basics of the data model its 'precise implementation' is excessive. It's like complaining about having to learn the precise details of your display server because someone tries to explain to you how windows in a typical window manager work. The underlying model of git is not terribly complicated, is distinct from (but maps reasonably closely to) its implementation, and it makes understanding all the operations on a repo and working directory a lot easier, as well as making it easier to google for help if you get stuck or want to do something new.
Git hides a lot of complexity, instead exposing an unintuitive set of commands to control your data. Multi-user distributed version control is a very complicated problem to which there will never be a simple solution. If you are willing to sacrifice some features, there are probably simpler solutions that would be more fitting with your work process.
I agree. Everyone should do their own cost benefit analysis. Git has a set of features and costs that make it highly suitable for some combinations of organization and project and not so suited for other combinations. There is no silver bullet.