1. 30

This is still vapourware, but I imagine it could be useful in cases where you need to send documents back and forth and you could have a discussion about it on the included wiki and you could merge changes from the container back and forth.

Yes this could be done more easily via the network but there are use cases where this is more complicated to set up. And I don’t want to get any more Document(45).doc emails.

  1.  

  2. 6

    I use Fossil at work and we’re moving to Git, mainly due to Fossil’s one main problem: no tools.

    I think Fossil is fine, but the descriptions in this document are little irksome.

    …because of the various version control systems available today, Git is the least user-friendly.

    …a Fossil-NG user to clone and use a repository out of GitHub while continuing to use the superior Fossil user interface.

    Fossil’s interface is nicer than Git’s but it’s not as good as the tools built around Git. Even though it has bug tracking and a wiki integrated, Fossil’s aren’t as good as others. Plus, things like JIRA and GitLab don’t work with Fossil at all. And that’s not even getting into the continuous integration systems. This is a side-effect of Fossil trying to be an all-in-one solution.

    Personally, I find Fossil’s diff/merge to be inferior to Git’s and when I have huge messes to deal with, I long for git difftool. I’ve also been stymied by the timeline command multiple times, probably because I’m used to git log. Fossil kind of demands that you use the GUI to work with it.

    1. 1

      I don’t think you would be willing to spend so much time writing a new scm if you didn’t really dislike git.

      It seems really ambitious wanting to support so many ‘legacy’ tools though.

    2. 2

      I really like some aspects of fossil, like the integrated issue tracker and wiki, but I really dislike not to be able be to squash commits.

      1. 1

        I also squash commits in my dev branches before merge[1] but it’s an easy philosophy to accept: the local history is permanent. That said, when I was using fossil I had a work flow of creating a temporary dev copy for each feature with all the mess and then a second “real” one that I would rsync the completed changes to and commit. The “real” one had a nice neat version of development.

        [1] Does anyone really need to see “and again”, “nope, typo”, “and fix the test”, “bump”, “wtf didn’t that work” and such from integration and what not?

        1. 1

          [1] Does anyone really need to see “and again”, “nope, typo”, “and fix the test”, “bump”, “wtf didn’t that work” and such from integration and what not?

          There’s the germ of an idea rattling around in my head that the answer to this question should be correlated with the answer to the question “should I record for posterity literally every single keystroke made in my text editor?”

          1. 1

            In my opinion, this relates to version control - in my opinion - being not complex enough. For example, you could have the best of both by having a notion of a “patch bundle” that wraps a couple of smaller changes.

            1. 1

              When I squash commits it’s not just about keeping the commit log tidy. Some mistakes or “wip” comments I really don’t want the world to see (though I’m fine with having them in a feature branch which I delete later).

      2. 2

        Do you know if the author of Fossil is looking for help contributing, or if they’re just thinking out loud?

        1. 2

          In the past, D. Richard Hipp was very welcoming to contributions to Fossil. I don’t think anything changed. Your best bet would be probably to start from participation in the mailing list.