5 ms·

Look, our lives (not just software lives, our entire lives) are dominated by crappy de facto standards. They are everywhere. They imposed themselves through ine

Look, our lives (not just software lives, our entire lives) are dominated by crappy de facto standards. They are everywhere. They imposed themselves through inertia, laziness and by virtue of being just a tad more useful than anything else at a time where everything else was terrible. Cable companies, Internet providers, social networks, foods, they surround us. But once in a while, we get stuck with a de facto standard that's actually quite good in its category. I happen to thing git is one of those. It took a while to get there, we had to suffer through decades of crappy source control systems until we eventually stumbled upon a good one. I'm happy with git. It has a terrible UI but beyond that, it's been an incredible force for progress not just in the open source world but increasingly inside companies as well. It fosters team work, encourages external contributions and once you've gotten used to its arcane flow, it enables all these aspects in pretty efficient ways. I'm happy with git. You should be too. And you should also be wary of making claims such as "Fossil is orders of magnitude more manageable than git". The burden of proof is on Fossil and beating git is a tall order.

aerique 9y ago
Also it feels like the OP is conflating Git and GitHub.
- interfixus 9y ago
  OP is not :)
  - aerique 9y ago
    Apologies :-)
- makapuf 9y ago
  It seems that the one responding to You, the op, is. Be careful guthub is nice but a proprietary monolith -> but git is nice. Hm ok but gitlab.
eesmith 9y ago
While I find Mercurial to be equally capable and easier to use.
- develop7 9y ago
  Mercurial is actually more capable (see "phases" and "changeset evolution"). From the standpoint of the end user, that is.
  - gmueckl 9y ago
    The sad part about Mercurial is that it is losing the battle against git because it was the better tool at the outset. The well-documented shittyness of the git user experience was the key to its success because it forced the creation of shiny wrappers and integrations to hide the abomination within. And this combination of gloss and peer pressure now manages to convince people that git is "good". Worse is better indeed...
    - dochtman 9y ago
      Personally (as a member of the Mercurial crew at the time) I believe GitHub has been a key part of Git winning. It provided a great UX for sharing code that Bitbucket despite valiant efforts of Jesper et al could just not match. I do think the time is just about right for someone to start a new generation that has compatibility with Git but provides a better user experience. Also in this category, see the Breezy effort that some old-time Bazaar hackers have started: https://www.youtube.com/watch?v=9vtToynsNSs https://www.youtube.com/watch?v=9vtToynsNSs
      - gmueckl 9y ago
        Considering how the hype cycle proceeds, any switch to a git successor will probably be slow. I would expect a replacement that comes into existence now to need five years to make itself known in the market and another five years to gather a critical mass. The actual tipping point would probably be reached around 15 to 20 years from now. That is an awfully long time.
selectnull 9y ago
This is one of the examples of well thought of, well written and in general excellent observations on the status of things in our lives. Well done sir! > I'm happy with git. You should be too. This is the only part of your comment I don't agree with. Just because you (and me too) are happy with git, that doesn't mean we should be advising other people to be happy with them. Let everybody decide for themselves what they should be happy about and if by some chance their unhappiness produces something even better, we all win again.
bch 9y ago
“Orders of magnitude” is probably out of line, and there’s always the case for “horses for courses” (or “tool for the job”, more broadly), but to say git is better than what appeared before (cvs, svn) could be interpreted as both true and useless. Pretty much any distributed source control management (DSCM) software is what modern development is using today, and better than the previous decades tools (cvs, svn). Git is but one example in the DSCM field. You mention it has a terrible UI, and I’m inclined to agree. The workflow might be described as terrible too, and maybe it’s a contributor to the UI. Git probably became what it is to a large extent because of the cult of personality of Linus, despite git itself. Sure it’s better than CVS, but in defence of GP post, it’s not unreasonable to push back because “good enough” (git) is standing in the way of “good” (fossil). That all said, cult or not, git has its network effect now, which is a powerful thing no matter what ones opinion of git is. I suspect we’re really probably remarkably in agreement wrt how fortunate we are in the code management field, and we should all be grateful, but that doesn’t preclude asking for more from our tools. We are privileged to be in a world where a fossil or mercurial, or bitkeeper user can “fall back” to git. We otherwise have an embarrassing amount of good choices for capable version control. Indeed, a good time to be alive.
renox 9y ago
I think that git is quite good, but I don't like the notion of 'squashing commits': when you squash commits you loose history! I would prefer to have a "fold/folder" of commits which could be manipulated as 'one commit' but would instead be a set of commit and you could look inside the folder if you need the full history.
- mjhoy 9y ago
  > I would prefer to have a "fold/folder" of commits which could be manipulated as 'one commit' You can get this, more or less, with the combination of using `git rebase` and `git merge --no-ff`.
- hota_mazi 9y ago
  Like everything, "squashing commits" has good use cases and bad use cases. They have all been documented to death but just as a quick reminder: Bad: squashing commits that have been pushed. Very bad. Not just because it rewrites history but because it's going to cause headaches to other people. Good: squashing commits in your own local branch before pushing to origin. In my opinion, this is not just good, it's excellent. Nobody on my team needs to know how many micro commits or dead ends and backtracks I've gone through before I reached the current shape of the code I'm about to push. I love squashing in this situation so I can rearrange and make the commit more pretty before it becomes public. On top of that, I'd argue that this kind of commit squashing contributes to making better commit logs.
  - Fice 9y ago
    In Fossil the good use case is supported by using private branches: when you merge a private branch into a public branch, only the merge commit is pushed, the private branch remains private.
- rbehrends 9y ago
  That's largely a UI issue. Look at Bazaar's hierarchical logs, for example [1]. I call it largely a UI issue because: 1. You can run `bzr log` on a git repository (with the bzr-git plugin). Hence it's a UI issue. 2. That operation still takes O(history size) time, because git repositories lack the necessary metadata to make the operation fast (hence: "largely" a UI issue). [1] https://bzrinit.com/05.html#hide https://bzrinit.com/05.html#hide
chriswarbo 9y ago
> once in a while, we get stuck with a de facto standard that's actually quite good in its category. I happen to thing git is one of those. I agree that git is pretty nice, and ubiquity is an important feature. For example, if you choose git you'll find loads of tooling, documentation, infrastructure, etc. that supports it. If you encounter a problem using it, there's almost certainly a fix or a detailed "won't fix" explanation in a blog post or on StackOverflow. > I'm happy with git. You should be too. Making git a de facto standard has won a VCS battle, but not the war; there's no reason to be complacent. It's fine to not care too much about VCS: just test the waters every now and again to make a quick cost/benefit assessment of the options; right now, that probably says "just use git". The majority of users should take this approach, and spend their time and effort on improving other things they care more about. Yet it's also fine to still care about VCS, try to invent or improve things, add more tooling or integrations for whatever non-standard system, and promote those things in order to nudge those cost/benefit analyses a little. If something becomes compelling enough, a feedback loop could make it the new de facto standard. Whilst I'm not particularly excited by Fossil, I am by other VCS ideas like the "patch theory" used by Darcs ( http://darcs.net http://darcs.net ). A major problem with Darcs is poor time-complexity, but enough people cared about the idea to make Pijul ( https://pijul.org https://pijul.org ) which doesn't have this problem. Does that make Pijul better than git? No, not least because of the project's immaturity and lack of tooling, integration, etc. Yet it nudges the cost/benefit a little, which might encourage more of those who care about VCS (say, those writing integration plugins) to support it, which nudges the cost/benefit a little more, and so on :)
interfixus 9y ago
I'm with you on a lot of points. But not really a huge believer in being told what I should and shouldn't do. 'Orders of magnitude' refers to a) the built-in web-interface and the bundled tools, b) the self-contained and super-easily compiled executable, and c) the one-file repository, consistency guaranteed, which I can stuff in my pocket and do with as I please.
rbehrends 9y ago
I disagree with the "progress" part. Git is still the 2005 state of the art, and in parts not even that (it took until 2015 to even support something as basic as multiple checkouts of the same repository via `git worktree`). Git is generally not very suitable for new features, because the repository format is very restrictive and has no room for adding new metadata (it's not impossible, but it's always going to be a hack). Most actual progress in version control has happened in systems other than Git, both open source and commercial (what Git has gotten is a lot more polish and ecosystem integration). My general criticism of Git isn't that it's bad, but that it's the lowest common denominator of modern version control and has resulted in technology being locked in to yesterday's state. At the same time, it's awfully complicated for how relatively basic its feature set is. It is not a bad tool, but it's not a particularly attractive one, either. Also: > It took a while to get there, we had to suffer through decades of crappy source control systems until we eventually stumbled upon a good one. Umm, what? Git wasn't the first attempt at improving upon CVS or SVN, and was arguably in some aspects worse than some of its predecessors (it often had higher implementation quality, but in terms of features it was also often a step backwards). I think lots of people are not familiar with PRCS (including the specced-out, but never implemented PRCS2), GNU arch, Monotone, or Darcs, not counting commercial or more esoteric ones.
- bfredl 9y ago
  > it took until 2015 to even support something as basic as multiple checkouts of the same repository via `git worktree` This feature was supported many years before that via a separate script.
  - rbehrends 9y ago
    I am familiar with git-new-workdir. However, git-new-workdir wasn't safe and could lose you data.
    - bfredl 9y ago
      This is a very vague statement, and contradicts your original claim. The way objects and branch references was set up by git-new-workdir was completely safe for git-gc not to lose other workdir's data. Other than that, keeping copies on another computer is the only way to reliably protect against data loss in any VCS system.

aerique 9y ago

Also it feels like the OP is conflating Git and GitHub.

interfixus 9y ago
OP is not :)
- aerique 9y ago
  Apologies :-)
makapuf 9y ago
It seems that the one responding to You, the op, is. Be careful guthub is nice but a proprietary monolith -> but git is nice. Hm ok but gitlab.

eesmith 9y ago

While I find Mercurial to be equally capable and easier to use.

develop7 9y ago
Mercurial is actually more capable (see "phases" and "changeset evolution"). From the standpoint of the end user, that is.
- gmueckl 9y ago
  The sad part about Mercurial is that it is losing the battle against git because it was the better tool at the outset. The well-documented shittyness of the git user experience was the key to its success because it forced the creation of shiny wrappers and integrations to hide the abomination within. And this combination of gloss and peer pressure now manages to convince people that git is "good". Worse is better indeed...
  - dochtman 9y ago
    Personally (as a member of the Mercurial crew at the time) I believe GitHub has been a key part of Git winning. It provided a great UX for sharing code that Bitbucket despite valiant efforts of Jesper et al could just not match. I do think the time is just about right for someone to start a new generation that has compatibility with Git but provides a better user experience. Also in this category, see the Breezy effort that some old-time Bazaar hackers have started: https://www.youtube.com/watch?v=9vtToynsNSs https://www.youtube.com/watch?v=9vtToynsNSs
    - gmueckl 9y ago
      Considering how the hype cycle proceeds, any switch to a git successor will probably be slow. I would expect a replacement that comes into existence now to need five years to make itself known in the market and another five years to gather a critical mass. The actual tipping point would probably be reached around 15 to 20 years from now. That is an awfully long time.

selectnull 9y ago

This is one of the examples of well thought of, well written and in general excellent observations on the status of things in our lives. Well done sir! > I'm happy with git. You should be too. This is the only part of your comment I don't agree with. Just because you (and me too) are happy with git, that doesn't mean we should be advising other people to be happy with them. Let everybody decide for themselves what they should be happy about and if by some chance their unhappiness produces something even better, we all win again.

bch 9y ago

“Orders of magnitude” is probably out of line, and there’s always the case for “horses for courses” (or “tool for the job”, more broadly), but to say git is better than what appeared before (cvs, svn) could be interpreted as both true and useless. Pretty much any distributed source control management (DSCM) software is what modern development is using today, and better than the previous decades tools (cvs, svn). Git is but one example in the DSCM field. You mention it has a terrible UI, and I’m inclined to agree. The workflow might be described as terrible too, and maybe it’s a contributor to the UI. Git probably became what it is to a large extent because of the cult of personality of Linus, despite git itself. Sure it’s better than CVS, but in defence of GP post, it’s not unreasonable to push back because “good enough” (git) is standing in the way of “good” (fossil). That all said, cult or not, git has its network effect now, which is a powerful thing no matter what ones opinion of git is. I suspect we’re really probably remarkably in agreement wrt how fortunate we are in the code management field, and we should all be grateful, but that doesn’t preclude asking for more from our tools. We are privileged to be in a world where a fossil or mercurial, or bitkeeper user can “fall back” to git. We otherwise have an embarrassing amount of good choices for capable version control. Indeed, a good time to be alive.

renox 9y ago

I think that git is quite good, but I don't like the notion of 'squashing commits': when you squash commits you loose history! I would prefer to have a "fold/folder" of commits which could be manipulated as 'one commit' but would instead be a set of commit and you could look inside the folder if you need the full history.

mjhoy 9y ago
> I would prefer to have a "fold/folder" of commits which could be manipulated as 'one commit' You can get this, more or less, with the combination of using `git rebase` and `git merge --no-ff`.
hota_mazi 9y ago
Like everything, "squashing commits" has good use cases and bad use cases. They have all been documented to death but just as a quick reminder: Bad: squashing commits that have been pushed. Very bad. Not just because it rewrites history but because it's going to cause headaches to other people. Good: squashing commits in your own local branch before pushing to origin. In my opinion, this is not just good, it's excellent. Nobody on my team needs to know how many micro commits or dead ends and backtracks I've gone through before I reached the current shape of the code I'm about to push. I love squashing in this situation so I can rearrange and make the commit more pretty before it becomes public. On top of that, I'd argue that this kind of commit squashing contributes to making better commit logs.
- Fice 9y ago
  In Fossil the good use case is supported by using private branches: when you merge a private branch into a public branch, only the merge commit is pushed, the private branch remains private.
rbehrends 9y ago
That's largely a UI issue. Look at Bazaar's hierarchical logs, for example [1]. I call it largely a UI issue because: 1. You can run `bzr log` on a git repository (with the bzr-git plugin). Hence it's a UI issue. 2. That operation still takes O(history size) time, because git repositories lack the necessary metadata to make the operation fast (hence: "largely" a UI issue). [1] https://bzrinit.com/05.html#hide https://bzrinit.com/05.html#hide

chriswarbo 9y ago

> once in a while, we get stuck with a de facto standard that's actually quite good in its category. I happen to thing git is one of those. I agree that git is pretty nice, and ubiquity is an important feature. For example, if you choose git you'll find loads of tooling, documentation, infrastructure, etc. that supports it. If you encounter a problem using it, there's almost certainly a fix or a detailed "won't fix" explanation in a blog post or on StackOverflow. > I'm happy with git. You should be too. Making git a de facto standard has won a VCS battle, but not the war; there's no reason to be complacent. It's fine to not care too much about VCS: just test the waters every now and again to make a quick cost/benefit assessment of the options; right now, that probably says "just use git". The majority of users should take this approach, and spend their time and effort on improving other things they care more about. Yet it's also fine to still care about VCS, try to invent or improve things, add more tooling or integrations for whatever non-standard system, and promote those things in order to nudge those cost/benefit analyses a little. If something becomes compelling enough, a feedback loop could make it the new de facto standard. Whilst I'm not particularly excited by Fossil, I am by other VCS ideas like the "patch theory" used by Darcs ( http://darcs.net http://darcs.net ). A major problem with Darcs is poor time-complexity, but enough people cared about the idea to make Pijul ( https://pijul.org https://pijul.org ) which doesn't have this problem. Does that make Pijul better than git? No, not least because of the project's immaturity and lack of tooling, integration, etc. Yet it nudges the cost/benefit a little, which might encourage more of those who care about VCS (say, those writing integration plugins) to support it, which nudges the cost/benefit a little more, and so on :)

interfixus 9y ago

I'm with you on a lot of points. But not really a huge believer in being told what I should and shouldn't do. 'Orders of magnitude' refers to a) the built-in web-interface and the bundled tools, b) the self-contained and super-easily compiled executable, and c) the one-file repository, consistency guaranteed, which I can stuff in my pocket and do with as I please.

rbehrends 9y ago

I disagree with the "progress" part. Git is still the 2005 state of the art, and in parts not even that (it took until 2015 to even support something as basic as multiple checkouts of the same repository via `git worktree`). Git is generally not very suitable for new features, because the repository format is very restrictive and has no room for adding new metadata (it's not impossible, but it's always going to be a hack). Most actual progress in version control has happened in systems other than Git, both open source and commercial (what Git has gotten is a lot more polish and ecosystem integration). My general criticism of Git isn't that it's bad, but that it's the lowest common denominator of modern version control and has resulted in technology being locked in to yesterday's state. At the same time, it's awfully complicated for how relatively basic its feature set is. It is not a bad tool, but it's not a particularly attractive one, either. Also: > It took a while to get there, we had to suffer through decades of crappy source control systems until we eventually stumbled upon a good one. Umm, what? Git wasn't the first attempt at improving upon CVS or SVN, and was arguably in some aspects worse than some of its predecessors (it often had higher implementation quality, but in terms of features it was also often a step backwards). I think lots of people are not familiar with PRCS (including the specced-out, but never implemented PRCS2), GNU arch, Monotone, or Darcs, not counting commercial or more esoteric ones.

bfredl 9y ago
> it took until 2015 to even support something as basic as multiple checkouts of the same repository via `git worktree` This feature was supported many years before that via a separate script.
- rbehrends 9y ago
  I am familiar with git-new-workdir. However, git-new-workdir wasn't safe and could lose you data.
  - bfredl 9y ago
    This is a very vague statement, and contradicts your original claim. The way objects and branch references was set up by git-new-workdir was completely safe for git-gc not to lose other workdir's data. Other than that, keeping copies on another computer is the only way to reliably protect against data loss in any VCS system.