7 ms·

I dont see the point of Fossil, I looked into it. The commands arent that much easier to understand. If I'm using an SCM anyway and I still need to use a cmd li

I dont see the point of Fossil, I looked into it. The commands arent that much easier to understand. If I'm using an SCM anyway and I still need to use a cmd line and I still need to memorize commands then I might just as well use git. And Git has Guis now.

blauditore 10y ago
Git has had several (first- and third-party) GUIs for a long time...
reitanqild 10y ago
If for nothing else then at least some people like me find it awesome that some people can still put all this into a small standalone and make it work nicely under multiple operating systems.
rkeene2 10y ago
Fossil's emphasis on recording history is very helpful. Additionally, the fact that the bug tracker, wiki, and technotes/milestones are all distributed as part of the same database is very helpful. Unversioned artifacts have been added recently, which are helpful for storing and optionally transmitting build artifacts associated with the repository. No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream. The code is simple and easy to modify -- I added tarball support (in addition to zip; but I think DRH rewrote the implementation that is in use) as well as S/MIME signing of commits (in addition to GPG -- to use X.509v3/PKI for more robust signing) I'd guess that the majority of projects are small development teams and this is the point of Fossil -- it works well for small development teams. When the Tcl developers were looking to migrate from Sourceforge to a new system, they picked Fossil over Git for a couple of reasons. Ease of use was one of them.
- vonuebelgarten 10y ago
  >No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream. But forcing this approach precludes you of, for example, easily splitting your existing changes in two commits if required. If changes to the same file are to be committed separately, a non-zero amount of copy-pasting, resetting, temporary files, etc. will be required. I see Git's separation of concerns of a strict superset for your use case. Just add an alias "git commit -a; git pull; git push".
  - rkeene2 10y ago
    Fossil's default mode, autosync, is more closely modeled by: git pull && if stillCommitingToBranchTip; then git commit -a; else echo "Not committing to the tip of the current branch" >&2; false; fi && git push You can turn autosync off in which case the fossil/git push/pull doesn't happen and your commit goes straight to the repository -- still without a staging area. This is my personal usage but, if two changes to the same file are to be committed separately (e.g., git add -p) then the commit that should have happened for those separate changes that was tested just got missed, or the commit that is occurring is untested and perhaps incoherent. That is to say, I build my staging area out of files on disk at the same time rather than building a changeset that may have never actually existed on disk.
  - lvh 10y ago
    That's true, but also means that there's a fake intermediate stage that never actually existed in the WT, and hence definitionally was never linted or tested.
    - vonuebelgarten 10y ago
      Iep. Running the tests over the new commits before pushing is still required. Usually not a big problem.
lvh 10y ago
The git UI is not necessarily consistent or pleasant. In many cases, this has improved over the years, but plenty of stuff still only makes sense via rote memorization, not because it actually matches what you're trying to do. http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
tacostakohashi 10y ago
Without having looked into the details... I do rather like the idea of an SCM with a built-in ticketing / documentation (wiki / markdown rendering system). These are both things that every project ends up needing, but end up with some different solution, which then ends up with a loose, brittle, custom integration with the SCM - using your ticket name for branches, but the having to look up the details on a website - checkin hooks, these kinds of hacks. It's not too difficult to imagine some simple, robust setup where the ticket state is and documentation (markdown) is store in the SCM, and you can view it either using the command-line, or fire up a local webserver embedded in the scm tool.
- qznc 10y ago
  On the other hand, it does not make much sense for ticketing and documentation to be distributed. They inherently must be centralized for a project.
  - tacostakohashi 10y ago
    I disagree completely - I think these things have the same properties as source code. Everybody thought SCM had to be centralized too, until it turned out that it didn't. I can see the same benefits of making local changes to tickets and documentation, then sharing those changes later when they're in a good state.
    - __david__ 10y ago
      You might like https://github.com/brandonson/evict https://github.com/brandonson/evict. I used to use `ditz` but it was abandoned years ago and was tied to Ruby 1.8 in a bad way. I've been meaning to switch to evict but haven't ever been able to get it to compile :-).
      - lvh 10y ago
        IIRC, ditz and evict and b-e and ticgit and... all don't solve a problem for public projects which fossil does: random people on the Internet need to be able to submit bug reports.
krylon 10y ago
Probably it's just me, but I could never wrap my head around git and gave up after a few attempts to get my feet wet with it. With Mercurial and Fossil, they worked very intuitively for me. Also, I like Fossil's tags. At work, I keep a repository of all the scripts I have written, and it really helps to associate individual commits with individual scripts. (I mean, don't get me wrong, if you like Git, by all means, use it. But for my workflow, it is far too complex.)

blauditore 10y ago

Git has had several (first- and third-party) GUIs for a long time...

reitanqild 10y ago

If for nothing else then at least some people like me find it awesome that some people can still put all this into a small standalone and make it work nicely under multiple operating systems.

rkeene2 10y ago

Fossil's emphasis on recording history is very helpful. Additionally, the fact that the bug tracker, wiki, and technotes/milestones are all distributed as part of the same database is very helpful. Unversioned artifacts have been added recently, which are helpful for storing and optionally transmitting build artifacts associated with the repository. No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream. The code is simple and easy to modify -- I added tarball support (in addition to zip; but I think DRH rewrote the implementation that is in use) as well as S/MIME signing of commits (in addition to GPG -- to use X.509v3/PKI for more robust signing) I'd guess that the majority of projects are small development teams and this is the point of Fossil -- it works well for small development teams. When the Tcl developers were looking to migrate from Sourceforge to a new system, they picked Fossil over Git for a couple of reasons. Ease of use was one of them.

vonuebelgarten 10y ago
>No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream. But forcing this approach precludes you of, for example, easily splitting your existing changes in two commits if required. If changes to the same file are to be committed separately, a non-zero amount of copy-pasting, resetting, temporary files, etc. will be required. I see Git's separation of concerns of a strict superset for your use case. Just add an alias "git commit -a; git pull; git push".
- rkeene2 10y ago
  Fossil's default mode, autosync, is more closely modeled by: git pull && if stillCommitingToBranchTip; then git commit -a; else echo "Not committing to the tip of the current branch" >&2; false; fi && git push You can turn autosync off in which case the fossil/git push/pull doesn't happen and your commit goes straight to the repository -- still without a staging area. This is my personal usage but, if two changes to the same file are to be committed separately (e.g., git add -p) then the commit that should have happened for those separate changes that was tested just got missed, or the commit that is occurring is untested and perhaps incoherent. That is to say, I build my staging area out of files on disk at the same time rather than building a changeset that may have never actually existed on disk.
- lvh 10y ago
  That's true, but also means that there's a fake intermediate stage that never actually existed in the WT, and hence definitionally was never linted or tested.
  - vonuebelgarten 10y ago
    Iep. Running the tests over the new commits before pushing is still required. Usually not a big problem.

lvh 10y ago

The git UI is not necessarily consistent or pleasant. In many cases, this has improved over the years, but plenty of stuff still only makes sense via rote memorization, not because it actually matches what you're trying to do. http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/

tacostakohashi 10y ago

Without having looked into the details... I do rather like the idea of an SCM with a built-in ticketing / documentation (wiki / markdown rendering system). These are both things that every project ends up needing, but end up with some different solution, which then ends up with a loose, brittle, custom integration with the SCM - using your ticket name for branches, but the having to look up the details on a website - checkin hooks, these kinds of hacks. It's not too difficult to imagine some simple, robust setup where the ticket state is and documentation (markdown) is store in the SCM, and you can view it either using the command-line, or fire up a local webserver embedded in the scm tool.

qznc 10y ago
On the other hand, it does not make much sense for ticketing and documentation to be distributed. They inherently must be centralized for a project.
- tacostakohashi 10y ago
  I disagree completely - I think these things have the same properties as source code. Everybody thought SCM had to be centralized too, until it turned out that it didn't. I can see the same benefits of making local changes to tickets and documentation, then sharing those changes later when they're in a good state.
  - __david__ 10y ago
    You might like https://github.com/brandonson/evict https://github.com/brandonson/evict. I used to use `ditz` but it was abandoned years ago and was tied to Ruby 1.8 in a bad way. I've been meaning to switch to evict but haven't ever been able to get it to compile :-).
    - lvh 10y ago
      IIRC, ditz and evict and b-e and ticgit and... all don't solve a problem for public projects which fossil does: random people on the Internet need to be able to submit bug reports.

krylon 10y ago

Probably it's just me, but I could never wrap my head around git and gave up after a few attempts to get my feet wet with it. With Mercurial and Fossil, they worked very intuitively for me. Also, I like Fossil's tags. At work, I keep a repository of all the scripts I have written, and it really helps to associate individual commits with individual scripts. (I mean, don't get me wrong, if you like Git, by all means, use it. But for my workflow, it is far too complex.)