7 ms·

Everybody uses git because it's the most sane and powerful source control tool there is.

PowerRangError 9y ago
Why do you think it's "the most" when there are equivalents? What does "most" mean? Most used was the point and the only salient quality that fits.
- parvenu74 9y ago
  This is a great question. Where I work we use TFSVC and the VP of Engineering is willing to green-light a switch to Git as long as we can make a data-driven, objective case for why Git is better. In other words: "the devs prefer it" or "using Git makes me happier" don't wash as valid reasons. Branching in Git is certainly much easier but the counter that "you can branch with TFSVC too" is true, even if it's slower and eats up your hard drive space faster...
  - erric 9y ago
    Slower and eats up disk space faster seem like valid data points to me.
  - UK-Al05 9y ago
    The Devs prefer it = improving the Devs workflow
    - lazyasciiart 9y ago
      That's not necessarily true. Everyone knows at least one dev who would prefer the world's stupidest workflow. And where it is true, it can directly contradict other priorities, like 'the devs prefer to check bug fixes directly into production because it saves them the work of staging'.
  - kadenshep 9y ago
    And merging branches in TFSVC is actually a nightmare.
barnabee 9y ago
[citation needed] Seriously, I find git very non-sane if not quite insane. I really liked darcs and still prefer Mercurial but sometimes the value attained by adopting standardisation overcomes the extra value in a "better" alternative, and so… here we are.
peatmoss 9y ago
Powerful? Certainly. Most sane? That’s a matter of perspective. I’m still a little shocked that git “won out” over mercurial. Even as Subversion was eating CVS, everybody knew distributed revision control was going to ultimately prevail. I was pretty sure Darcs wasn’t going to achieve popularity, but I’d have bet anything that Mercurial would be the successor to Subversion. It was far more natural / similar for anyone who's ever worked with CVS/SVN.
- jdright 9y ago
  Python killed any chance of success for Mercurial.
  - peatmoss 9y ago
    Agreed, but I’d have guessed that the Windows / git compatibility horrorshow (at least in the early days) would have nuked git’s chances as well. I’d have bet on the success of more friendly CLI UX and comparatively easier time on Windows even with the disamenity of Python.
  - pseudalopex 9y ago
    Why do you say that?
luckydude 9y ago
I've built two source management systems (NSElite, internal to Sun, and bitkeeper, now open source at bitkeeper.org). Calling Git sane just makes it clear that you haven't used a sane source management system. Git has no file object, it versions the repo, not files. There is one graph for all files, the repo graph. So the common ancester for a 3 way diff is the repo GCA, which could very well be miles away from the file GCA if you have a graph per file (like BitKeeper does). No file object means no create event recorded, no rename event recorded, no delete event recorded. If you ask for the diffs on "src/foo.c" all Git can do is look at each commit and see if "src/foo.c" was modified in that commit. That's insanely slow in a big repo. And it completely ignores the fact that src/foo.c got moved to src/libc/foo.c years ago and there is a different src/foo.c that is completely unrelated. There is an option to try and intuit the renames when you are spitting out diffs but noone uses that because it's even more insanely slow. Git is basically a tarball server. Calling that a source management system is an enormous stretch. Calling it a sane and powerful source control tool is just not supported by the facts, calling "the most ..." is laughable. Yeah, I get it, Git won. You all lost out on "the most sane and powerful" as a result. Which sort of doesn't matter since everyone thinks GitHub is source management.
- jperras 9y ago
  > Git has no file object, it versions the repo, not files. As someone who has used (in a professional setting) version control systems ranging from RCA to SVN to the current crop (git, mercurial, even darcs), the fact that git versions the repository as a whole instead of individual files is a godsend. You've not known hell until you've had to deal with an RCA/CVS repository with 15+ years of history and thousands of files, each that maintains their own version history (and associated version number!). I'd gladly take the comparative "slowness" of git when dealing with large repositories. > Git is basically a tarball server. Calling that a source management system is an enormous stretch. What, in your opinion, is the definition of a version control system then?
  - luckydude 9y ago
    A version control system is an accurate audit trail of everything that has happened in the repository. Every create, delete, rename, every rwx mode change, every content change. In BitKeeper files work like they do in Unix, there is a (globally) unique name for each file object. Where the object lives in the repository is an attribute of that object, as are the contents, the permissions, who has changed etc. Here's a super common workflow that's easy in BitKeeper and miserable in Git. I'm debugging an assert. I want to see who added the assert. I pop into the gui that shows me the per file graph and contents, search for the assert, hover over the rev and see that it was done a long time ago. I look in the area above the assert and I see a recent change, hover over that, see the comments and go "hmm, maybe this". Double click that line and I pop into a different gui that shows me the whole commit that contains that suspect line. Note that because I have a graph per file, I have checkin comments per file. More work for you poor committers but a godsend for us debuggers. More breadcrumbs are more better. In Git, less breadcrumbs, single commit message. Git wants to go from the rev to the commit, it's miserable to look around in a file and then go backwards to the commit. When I was supporting BitKeeper our average response time to bug report or a crash report was 25 minute. 24x7. The only reason it was that long was because we were all in North America so there was a window where we were all asleep. Response time 6am-6pm PST was typically under 5 minutes. And I credit the fact that the tool accurately recorded everything and you could find the history really easily. Oh, and it didn't slow down as the repo got big. Git is fine in little repos but it sucks pretty hard in big ones. Sucks even worse if you are on NFS. I can dig up benchmarks, we built up a synthetic 4M file repo and ran a bunch of tests on it (it was a modified version of the facebook repo builder, the facebook one had some stuff in it that made Git look incredibly bad, we looked at that and decided that wasn't real world or fair, we took that part out).
tzs 9y ago
If you don't need a distributed system, I'd argue that Subversion is at least as sane as anything else, at least at the plumbing level, once you realize that it is not so much a VCS as essentially a remote file system with atomic multi-file operations, automatic sequentially numbered annotated snapshots after write operations, and near zero cost copy on write copying. You establish a naming convention on top of that to use it as a VCS. For example, one common such convention is to have directories named "trunk", "tags", and "branches" at the top level, with your projects living in subdirectories under "trunk". Under this convention the way you represent a tag is by simply copying your project directory from trunk/my_project to a new directory named tags/my_project/tagname. Similar for branching...just copy to branches/my_project/branch_name. Don't like that convention? Develop your own that fits your work better.
- peatmoss 9y ago
  > If you don't need a distributed system, I'd argue that Subversion is at least as sane as anything else Oh my yes. Binary diffs were lovely. Also, support for large assets. For reproducible data science work, you’re going to need at least code and data. One of those things is a total PIA with git if the data aren’t trivially small. I wonder how fossil does in this regard...

Why do you think it's "the most" when there are equivalents? What does "most" mean? Most used was the point and the only salient quality that fits.

parvenu74 9y ago
This is a great question. Where I work we use TFSVC and the VP of Engineering is willing to green-light a switch to Git as long as we can make a data-driven, objective case for why Git is better. In other words: "the devs prefer it" or "using Git makes me happier" don't wash as valid reasons. Branching in Git is certainly much easier but the counter that "you can branch with TFSVC too" is true, even if it's slower and eats up your hard drive space faster...
- erric 9y ago
  Slower and eats up disk space faster seem like valid data points to me.
- UK-Al05 9y ago
  The Devs prefer it = improving the Devs workflow
  - lazyasciiart 9y ago
    That's not necessarily true. Everyone knows at least one dev who would prefer the world's stupidest workflow. And where it is true, it can directly contradict other priorities, like 'the devs prefer to check bug fixes directly into production because it saves them the work of staging'.
- kadenshep 9y ago
  And merging branches in TFSVC is actually a nightmare.

barnabee 9y ago

[citation needed] Seriously, I find git very non-sane if not quite insane. I really liked darcs and still prefer Mercurial but sometimes the value attained by adopting standardisation overcomes the extra value in a "better" alternative, and so… here we are.

peatmoss 9y ago

Powerful? Certainly. Most sane? That’s a matter of perspective. I’m still a little shocked that git “won out” over mercurial. Even as Subversion was eating CVS, everybody knew distributed revision control was going to ultimately prevail. I was pretty sure Darcs wasn’t going to achieve popularity, but I’d have bet anything that Mercurial would be the successor to Subversion. It was far more natural / similar for anyone who's ever worked with CVS/SVN.

jdright 9y ago
Python killed any chance of success for Mercurial.
- peatmoss 9y ago
  Agreed, but I’d have guessed that the Windows / git compatibility horrorshow (at least in the early days) would have nuked git’s chances as well. I’d have bet on the success of more friendly CLI UX and comparatively easier time on Windows even with the disamenity of Python.
- pseudalopex 9y ago
  Why do you say that?

luckydude 9y ago

I've built two source management systems (NSElite, internal to Sun, and bitkeeper, now open source at bitkeeper.org). Calling Git sane just makes it clear that you haven't used a sane source management system. Git has no file object, it versions the repo, not files. There is one graph for all files, the repo graph. So the common ancester for a 3 way diff is the repo GCA, which could very well be miles away from the file GCA if you have a graph per file (like BitKeeper does). No file object means no create event recorded, no rename event recorded, no delete event recorded. If you ask for the diffs on "src/foo.c" all Git can do is look at each commit and see if "src/foo.c" was modified in that commit. That's insanely slow in a big repo. And it completely ignores the fact that src/foo.c got moved to src/libc/foo.c years ago and there is a different src/foo.c that is completely unrelated. There is an option to try and intuit the renames when you are spitting out diffs but noone uses that because it's even more insanely slow. Git is basically a tarball server. Calling that a source management system is an enormous stretch. Calling it a sane and powerful source control tool is just not supported by the facts, calling "the most ..." is laughable. Yeah, I get it, Git won. You all lost out on "the most sane and powerful" as a result. Which sort of doesn't matter since everyone thinks GitHub is source management.

jperras 9y ago
> Git has no file object, it versions the repo, not files. As someone who has used (in a professional setting) version control systems ranging from RCA to SVN to the current crop (git, mercurial, even darcs), the fact that git versions the repository as a whole instead of individual files is a godsend. You've not known hell until you've had to deal with an RCA/CVS repository with 15+ years of history and thousands of files, each that maintains their own version history (and associated version number!). I'd gladly take the comparative "slowness" of git when dealing with large repositories. > Git is basically a tarball server. Calling that a source management system is an enormous stretch. What, in your opinion, is the definition of a version control system then?
- luckydude 9y ago
  A version control system is an accurate audit trail of everything that has happened in the repository. Every create, delete, rename, every rwx mode change, every content change. In BitKeeper files work like they do in Unix, there is a (globally) unique name for each file object. Where the object lives in the repository is an attribute of that object, as are the contents, the permissions, who has changed etc. Here's a super common workflow that's easy in BitKeeper and miserable in Git. I'm debugging an assert. I want to see who added the assert. I pop into the gui that shows me the per file graph and contents, search for the assert, hover over the rev and see that it was done a long time ago. I look in the area above the assert and I see a recent change, hover over that, see the comments and go "hmm, maybe this". Double click that line and I pop into a different gui that shows me the whole commit that contains that suspect line. Note that because I have a graph per file, I have checkin comments per file. More work for you poor committers but a godsend for us debuggers. More breadcrumbs are more better. In Git, less breadcrumbs, single commit message. Git wants to go from the rev to the commit, it's miserable to look around in a file and then go backwards to the commit. When I was supporting BitKeeper our average response time to bug report or a crash report was 25 minute. 24x7. The only reason it was that long was because we were all in North America so there was a window where we were all asleep. Response time 6am-6pm PST was typically under 5 minutes. And I credit the fact that the tool accurately recorded everything and you could find the history really easily. Oh, and it didn't slow down as the repo got big. Git is fine in little repos but it sucks pretty hard in big ones. Sucks even worse if you are on NFS. I can dig up benchmarks, we built up a synthetic 4M file repo and ran a bunch of tests on it (it was a modified version of the facebook repo builder, the facebook one had some stuff in it that made Git look incredibly bad, we looked at that and decided that wasn't real world or fair, we took that part out).

tzs 9y ago

If you don't need a distributed system, I'd argue that Subversion is at least as sane as anything else, at least at the plumbing level, once you realize that it is not so much a VCS as essentially a remote file system with atomic multi-file operations, automatic sequentially numbered annotated snapshots after write operations, and near zero cost copy on write copying. You establish a naming convention on top of that to use it as a VCS. For example, one common such convention is to have directories named "trunk", "tags", and "branches" at the top level, with your projects living in subdirectories under "trunk". Under this convention the way you represent a tag is by simply copying your project directory from trunk/my_project to a new directory named tags/my_project/tagname. Similar for branching...just copy to branches/my_project/branch_name. Don't like that convention? Develop your own that fits your work better.

peatmoss 9y ago
> If you don't need a distributed system, I'd argue that Subversion is at least as sane as anything else Oh my yes. Binary diffs were lovely. Also, support for large assets. For reproducible data science work, you’re going to need at least code and data. One of those things is a total PIA with git if the data aren’t trivially small. I wonder how fossil does in this regard...