5 ms·

I think I have a case of "Git Stockholm Syndrome"; I don't find any of these terms terribly confusing, but I think that's in no small part because I haven't rea

I think I have a case of "Git Stockholm Syndrome"; I don't find any of these terms terribly confusing, but I think that's in no small part because I haven't really learned any other systems, and have been entrenched in Git since like 2011. Looking back, I suspect that I was extremely confused when starting out, but was pretending I wasn't to try and seem cool.

raincole 3y ago
The only other version control that I used is Plastic SCM, and honestly Stockholm Syndrome or not, I like git much more.
- tombert 3y ago
  Someone told me that I really need to check out Mercurial for its binary diffing stuff, and as I've gotten more into 3d modeling in the last year then that might actually buy me something. However, now that bitbucket has dropped Mercurial support, I'm not entirely sure where I can easily push a mercurial repo for backup. For better or worse, I am extremely dependent on Gitlab to backup my code so I'm not risking my work on a potentially failing hard disk/ssd.
  - raincole 3y ago
    > 3D modeling I don't know. For large binary files I still use Google Drive as backup (I know 3D models are not necessarily "large" by today's standard) One can use git LFS, but there isn't an easy way to free up the storage them occupy from the history. And GitHub LFS is about 5 times more expensive than Google Drive per GB.
    - tombert 3y ago
      These are just CAD-style models for functional robotic parts, not game assets or anything, so they're not actually very large as they're pretty utilitarian, but they do change a lot. As of right now, I'm just pushing the binary files to Gitlab with vanilla git, and at least thus far Gitlab hasn't complained to me. I figure that the moment Gitlab sends me a nastygram about it, I'll move to S3 or Google Storage or something.
    - funcDropShadow 3y ago
      There is also git annex for large binary files and other things.
  - pseudalopex 3y ago
    https://wiki.mercurial-scm.org/MercurialHosting https://wiki.mercurial-scm.org/MercurialHosting
    - tombert 3y ago
      I saw this, but the stuff I'm working on isn't (for the moment) open source, which most of them require. That said, I will give the Perforce one a look.
      - pseudalopex 3y ago
        I think most of them have private repos. But not most of the free services.
jeltz 3y ago
I had used cvs and svn before I used git, and compared to svn git was much easier to understand.
bad_username 3y ago
I knew that I had Stockholm syndrome when I took a look at the CLI of the Fossil VCS. It is so... straightforward.
- tombert 3y ago
  Fossil looks neat, but it didn't look "sufficiently better" than Git for me to bother changing, especially due to all the services that support Git out of the box. What does Fossil buy you over Git?
  - PH95VuimJjqBqy 3y ago
    in terms of Fossil as an SCM, it's very similar outside of the author's views of rebase (which I happen to agree with). https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md In terms of Fossil as a technology, it's an SCM with built-in project management tools (wiki, forums, bug tracker, etc) so it does much more than git does. The front page has more info: https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki
    - wrkta 3y ago
      I don't really agree with this assessment of rebase. I think there is value in squashing commits on dev branches into logically distinct sets to keep the log cleaner. In the case where the reason code is doing something that is not obvious I think that explaining the reasoning or the journey to that point in a commit message is clearer than the complete history of trial and error to reach that state.
      - PH95VuimJjqBqy 3y ago
        This is one of those things where both sides have a point based upon their values as developers.
  - myaccountonhn 3y ago
    Git (not github) was built for bazaar style decentralized development where people might contribute a single patch or two, and it scales really well (see Linux). People don’t even need an account to contribute, they can just send a patch via email. Fossil was built for cathedral style development, where you’re a small team of trusted contributors. You get offline first issue tracker, wiki, forum, chat etc. out of the box and integrated into an easy to backup solution. Allegedly it doesn’t scale as well though. With hosted services like Github, I feel like fossil doesn’t buy much more than offline first capability and simpler to use. However if you self host, fossil is dead simple run (single binary) and to backup due to it generating a single SQLite file and it’s easy to stream changes elsewhere. Setting up git with gitolite, email list, issue tracker etc is much harder (though I’ve heard gitea is easy to use).

raincole 3y ago

The only other version control that I used is Plastic SCM, and honestly Stockholm Syndrome or not, I like git much more.

tombert 3y ago
Someone told me that I really need to check out Mercurial for its binary diffing stuff, and as I've gotten more into 3d modeling in the last year then that might actually buy me something. However, now that bitbucket has dropped Mercurial support, I'm not entirely sure where I can easily push a mercurial repo for backup. For better or worse, I am extremely dependent on Gitlab to backup my code so I'm not risking my work on a potentially failing hard disk/ssd.
- raincole 3y ago
  > 3D modeling I don't know. For large binary files I still use Google Drive as backup (I know 3D models are not necessarily "large" by today's standard) One can use git LFS, but there isn't an easy way to free up the storage them occupy from the history. And GitHub LFS is about 5 times more expensive than Google Drive per GB.
  - tombert 3y ago
    These are just CAD-style models for functional robotic parts, not game assets or anything, so they're not actually very large as they're pretty utilitarian, but they do change a lot. As of right now, I'm just pushing the binary files to Gitlab with vanilla git, and at least thus far Gitlab hasn't complained to me. I figure that the moment Gitlab sends me a nastygram about it, I'll move to S3 or Google Storage or something.
  - funcDropShadow 3y ago
    There is also git annex for large binary files and other things.
- pseudalopex 3y ago
  https://wiki.mercurial-scm.org/MercurialHosting https://wiki.mercurial-scm.org/MercurialHosting
  - tombert 3y ago
    I saw this, but the stuff I'm working on isn't (for the moment) open source, which most of them require. That said, I will give the Perforce one a look.
    - pseudalopex 3y ago
      I think most of them have private repos. But not most of the free services.

jeltz 3y ago

I had used cvs and svn before I used git, and compared to svn git was much easier to understand.

bad_username 3y ago

I knew that I had Stockholm syndrome when I took a look at the CLI of the Fossil VCS. It is so... straightforward.

tombert 3y ago
Fossil looks neat, but it didn't look "sufficiently better" than Git for me to bother changing, especially due to all the services that support Git out of the box. What does Fossil buy you over Git?
- PH95VuimJjqBqy 3y ago
  in terms of Fossil as an SCM, it's very similar outside of the author's views of rebase (which I happen to agree with). https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md In terms of Fossil as a technology, it's an SCM with built-in project management tools (wiki, forums, bug tracker, etc) so it does much more than git does. The front page has more info: https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki
  - wrkta 3y ago
    I don't really agree with this assessment of rebase. I think there is value in squashing commits on dev branches into logically distinct sets to keep the log cleaner. In the case where the reason code is doing something that is not obvious I think that explaining the reasoning or the journey to that point in a commit message is clearer than the complete history of trial and error to reach that state.
    - PH95VuimJjqBqy 3y ago
      This is one of those things where both sides have a point based upon their values as developers.
- myaccountonhn 3y ago
  Git (not github) was built for bazaar style decentralized development where people might contribute a single patch or two, and it scales really well (see Linux). People don’t even need an account to contribute, they can just send a patch via email. Fossil was built for cathedral style development, where you’re a small team of trusted contributors. You get offline first issue tracker, wiki, forum, chat etc. out of the box and integrated into an easy to backup solution. Allegedly it doesn’t scale as well though. With hosted services like Github, I feel like fossil doesn’t buy much more than offline first capability and simpler to use. However if you self host, fossil is dead simple run (single binary) and to backup due to it generating a single SQLite file and it’s easy to stream changes elsewhere. Setting up git with gitolite, email list, issue tracker etc is much harder (though I’ve heard gitea is easy to use).