4 ms·

Fossil's new(ish) semi-automatic bidirectional interaction with Git mirrors has finally made Mercurial replaceable for me. However, it is hard to ignore that th

Fossil's new(ish) semi-automatic bidirectional interaction with Git mirrors has finally made Mercurial replaceable for me. However, it is hard to ignore that the IT world has mostly decided to settle with whatever is the most commonly used right now, no matter if it is actually the best solution - so at least when it comes to DVCS, the war seems to be over.

StavrosK 7y ago
How does that interaction work? Last I checked, it wasn't great or it was too much of a hassle (I don't remember exactly).
- rhabarba 7y ago
  Exporting to Git: You set a "Git mirror" once, optionally with a remote URI, and call fossil's export routine. Example: I wrote a cronjob that runs once every night that does nothing but update my Git mirrors from the current Fossils. cd $FOSSILDIR for f in *; do /usr/local/bin/fossil git export -q -R $f done Importing works... similarly. :-)
  - StavrosK 7y ago
    Hmm, but does importing keep all your issues, etc? I imagine it just imports the new commits?
    - rhabarba 7y ago
      Fossil cannot import things from Git which Git does not store. Git has no issue tracker.
      - StavrosK 7y ago
        Right, but are the local Fossil issues preserved during import?
        rhabarba 7y ago
        Sure.
        rhabarba 7y ago
        ... (I guess. Need to test that.)
0_gravitas 7y ago
But this doesn't hold for things like languages, adoption of new tech over old (no matter how prominent it is) happens all the time, but it usually starts at the small scale, like start-ups. It definitely takes a hell of a long time, and it would probably never usurp 100% of gits usership (or even 50%), but it will probably be used in some capacity. Of course Java's still as big as ever, but we have seen an uptick in relatively new languages still coming into use (I think of things like Elm/Elixir).
- int_19h 7y ago
  There was always an "uptick in relatively new languages coming into use", as long as I remember. The problem is that most of them die before they mature, and some achieve a "peak cool" but then fade into obscurity, or find a relatively small niche. Very few new languages ever get popular enough to get into the top 10 on a permanent basis, and even fewer displace a large player that was previously popular. Meanwhile, most code running on any given computing device is still written in C, C++, or Java. The article is basically arguing that we're likely to see the same state of affairs in VCS land. Sure, there will still be new ones coming into use, and fading out, or finding small niches - but Git will remain dominant for decades to come.
theamk 7y ago
Does not Fossil’s “no rebases” philosophy bother you? IMHO, the ability to “commit early, commit often” and to squash/rebase original work later into clean and understandable commits is one of the best features of Git.
- SQLite 7y ago
  https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md
  - theamk 7y ago
    Right - and I think that point 6 and 7 are exactly why I use rebase daily, and why I will never use Fossil. The version control history is made for reading by other people, so it is a story. After all, we only write the commit once, but people will read it many more times. (This is especially true if there are code reviews involved) I am an imperfect programmer. My work-in-progres is often broken, and even fails to compile. Sometimes I will refactor interface only, and will want to checkpoint my work before I go and refactor implementation as well. Sometimes I will choose a totally wrong approach and revert it later. Sometimes I will disable/break large part of system on purpose, to make testing easier. And I often do stupid data-destroying mistakes, so I want an ability to save/store all the past versions, even if they are completely broken. My “raw” commits may look like: “start on feature X”, “refactor interface Y”, “more work on feature X”, “wip commit”, “fix tests”, “fix performance”, “fix more tests”. Does any future reader care it took me 3 commits to get the tests right? Do they care that I discovered the need to refactor only while I was halfway in feature X implementation? Do they want to see a repo that won’t even compile? Do they want to hav to cherry-pick dozens of commits to get the tests to pass? I don’t think so. The final version will only have two commits, “refactor” and “feature X”. It would be obvious to everyone which lines of code are associated with which change. Each revision will be buildable, and will pass all tests - so bisect will actually work. (If rebase support is missing, it is possible to “fake” it by having multiple checkouts and manually copying files around. But this is much more error prone and dangerous. I have spent plenty of time with SVN/CVS, manually copying files and applying patches - and I can tell that having this integrated with version control is much more pleasant)

StavrosK 7y ago

How does that interaction work? Last I checked, it wasn't great or it was too much of a hassle (I don't remember exactly).

rhabarba 7y ago
Exporting to Git: You set a "Git mirror" once, optionally with a remote URI, and call fossil's export routine. Example: I wrote a cronjob that runs once every night that does nothing but update my Git mirrors from the current Fossils. cd $FOSSILDIR for f in *; do /usr/local/bin/fossil git export -q -R $f done Importing works... similarly. :-)
- StavrosK 7y ago
  Hmm, but does importing keep all your issues, etc? I imagine it just imports the new commits?
  - rhabarba 7y ago
    Fossil cannot import things from Git which Git does not store. Git has no issue tracker.
    - StavrosK 7y ago
      Right, but are the local Fossil issues preserved during import?
      - rhabarba 7y ago
        Sure.
      - rhabarba 7y ago
        ... (I guess. Need to test that.)

0_gravitas 7y ago

But this doesn't hold for things like languages, adoption of new tech over old (no matter how prominent it is) happens all the time, but it usually starts at the small scale, like start-ups. It definitely takes a hell of a long time, and it would probably never usurp 100% of gits usership (or even 50%), but it will probably be used in some capacity. Of course Java's still as big as ever, but we have seen an uptick in relatively new languages still coming into use (I think of things like Elm/Elixir).

int_19h 7y ago
There was always an "uptick in relatively new languages coming into use", as long as I remember. The problem is that most of them die before they mature, and some achieve a "peak cool" but then fade into obscurity, or find a relatively small niche. Very few new languages ever get popular enough to get into the top 10 on a permanent basis, and even fewer displace a large player that was previously popular. Meanwhile, most code running on any given computing device is still written in C, C++, or Java. The article is basically arguing that we're likely to see the same state of affairs in VCS land. Sure, there will still be new ones coming into use, and fading out, or finding small niches - but Git will remain dominant for decades to come.

theamk 7y ago

Does not Fossil’s “no rebases” philosophy bother you? IMHO, the ability to “commit early, commit often” and to squash/rebase original work later into clean and understandable commits is one of the best features of Git.

SQLite 7y ago
https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md
- theamk 7y ago
  Right - and I think that point 6 and 7 are exactly why I use rebase daily, and why I will never use Fossil. The version control history is made for reading by other people, so it is a story. After all, we only write the commit once, but people will read it many more times. (This is especially true if there are code reviews involved) I am an imperfect programmer. My work-in-progres is often broken, and even fails to compile. Sometimes I will refactor interface only, and will want to checkpoint my work before I go and refactor implementation as well. Sometimes I will choose a totally wrong approach and revert it later. Sometimes I will disable/break large part of system on purpose, to make testing easier. And I often do stupid data-destroying mistakes, so I want an ability to save/store all the past versions, even if they are completely broken. My “raw” commits may look like: “start on feature X”, “refactor interface Y”, “more work on feature X”, “wip commit”, “fix tests”, “fix performance”, “fix more tests”. Does any future reader care it took me 3 commits to get the tests right? Do they care that I discovered the need to refactor only while I was halfway in feature X implementation? Do they want to see a repo that won’t even compile? Do they want to hav to cherry-pick dozens of commits to get the tests to pass? I don’t think so. The final version will only have two commits, “refactor” and “feature X”. It would be obvious to everyone which lines of code are associated with which change. Each revision will be buildable, and will pass all tests - so bisect will actually work. (If rebase support is missing, it is possible to “fake” it by having multiple checkouts and manually copying files around. But this is much more error prone and dangerous. I have spent plenty of time with SVN/CVS, manually copying files and applying patches - and I can tell that having this integrated with version control is much more pleasant)