Comment by rkeene2 | Hacker News Reader

Comment by rkeene2 | Hacker News Reader

Parent Full thread

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.

>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".

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.

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.

Iep. Running the tests over the new commits before pushing is still required. Usually not a big problem.

Reply on news.ycombinator.com