Though I just vented in another comment about fossil, I'll admit that all of my experience was in the pre-agentic era. Since an agent won't be as easily annoyed (heck, it happily belts out sqlite's tedious schema alternation dance without pause), I'm curious to try pointing it fossil as the scm for a project.
Fossil is extremely frustrating to me. There are so many parts that I'm drawn to, but then are there showstoppers that prevent real adoption (by me). I've used it in earnest a number of times. Their immutability stance is at the root of the problems. Lack of rebase is most infamous, but you can't even edit a ticket description! Make a typo or error in the description, and you're expected to append more notes, or delete and recreate the ticket.
I really love the idea of a powerful, shrink-wrapped scm + ticketing etc. system, and I'm a sqlite fan, but fossil hasn't worked out for me.
I think it's less about immutability and more about visibility.
The argument made by the Fossil project, AFAIU, is that it has a better log view than git and has better traceability through SQL based search in addition t the cli and web interface.
To me, associating a wiki page to a commit makes way more sense than as a commit message that's part of the commit. This way the message can give a summary and then the detail is given in full-fledged markup file that has its own version history.
Totally fair if that's not something that works for you, though.
Every time fossil comes up, I hear this same issue - "why is there no rebase?"
And honestly, I've never been able to get this argument. It's a version management system! It's supposed to maintain the history of what's been done, both good and bad. In fact, that's the whole point of a VCS, isn't it?
IMHO, if we want to show a different path than what's been actually taken for the codebase to reach where it is now, we might as well use a network drive to store the different versions. Why bother with a VCS then?
I use both, and I prefer fossil. But my coworkers hate fossil because they can't fake their commits to make them look good. This is something I actually like about fossil: git has tools just to make things look pretty even if they can cause serious headaches (rebase), so users are skewed towards good looking timelines made with dirty commits then rearranged and squashed. OTOH fossil forces you to do your best but accept that sometimes you botch it, and have to mark a commit as "does not build".
And I don't know why (forces you to review and cofirm?), but I had never commited unwanted stuff with fossil. But I had with git, probably by using the -am flag without realising a whole new dir is now in the scope.
This prioritises accuracy/history of what happened, but this has significant disadvantages and practically no advantages (other than "accuracy of what happened".
There are cases where you really do want an append-only leger, where tampering with history is malicious. -- But, generally, it's preferable to be presented with something tidy.
From some other comment in this thread, I get the impression it's possible to re-present a set of changes in a clean/tidy way? That seems a better way of putting it. "You can still have a clean view into a set of changes while preserving an accurate history of what changed".
What's hard to understand is why you'd be against the idea of tidy communication/presentation of changes in the first place.
Can you help provide examples from your development experience where "knowing the accurate history of what happened" was a very big advantage, to the extent where not having this knowledge would have made things very difficult?
Here a developer thought that redis would be a good add to the stack, so we decided he should try. It turned out that it didn't fit, mainly because it needed to touch code in more places than anticipated. We went back to starting point, but the project now carries a "no more redis/cache attempts before reading this one, please" fossil. New attempts can't say "oh, I didn't know this was attempted before".
With git, this kind of experiment would be hidden with a "reset hard", and probably will happen again when people forgets, someone says "didn't we try that a year ago?" but we have no records.
This is very helpful in small private teams, not so much in biggest teams (kernel), pass-by PR environments (github), or public CV-oriented repos (no mistakes allowed there, only pretty linear timelines).
This sounds more like some elitism. Who cares how your coworkers got there, the point is to have good history at the origin. People don't need to see your dirty laundy, there is nothing interesting about it.
> People don't need to see your dirty laundy, there is nothing interesting about it.
We disagree here, thus we prefer different tools. Nothing elitist here.
I have seen git people throwing away repos and start again just to hide mistakes/pivoting and look "pro" and "right from the start". Or worse, I have seen people botching repos to others rewritting history just to make them look clean. I embrace mistakes, and sometimes they become useful later to replay train of thoughs.
In the most common git setups, you never force-push to master - so a coworker can't rewrite history of master branch. Forges have protection rules, but even if your hosting does not, then the "git pull" will throw a ton of errors after history rewrites. So both fossil and git are similar in that regards.
On the other hand, unpushed branches can be rewritten any time in git.. but this applies to fossil as well. If you have not pushed your fossil changes, it's just a file on disk - you can delete it without pushing and no one will ever know you had intermediate version. Or work in "git" and only export to fossil (or svn or cvs or whatever) once things work.
Secrets that is committed anyway has to be assumed as compromised. So those secrets must be immediately changed. Removing it from history would help a bit, but is not a reliable mitigation.
History is immutable ONCE it’s merged. Prior to that, it’s malleable. We rewrite our branch history fairly often. I’ll take a big PR that’s ready, and rewrite the history in a way that tells clear story. This lets me stack PRs so it’s easier for coworkers to digest the work. It hides the messy reality of how it was constructed. It lets the development process follow evolutionary design, without review being miserable at the end of the day. This also makes git-blame 6 months later way more useful, as the commits end up much tidier with better messages and clearer story being told.
This was CVS/SVN approach, and that's the reason git won so quickly (no, it was not github like some people claimed, I've seen git become popular in my circle before github was a thing)
I am not sure if you used CSV/SVN before - I did. It maintained the history of what was done in a very immutable way. The branches were heavy-weight and were only used for Serious Business, we generally had a person responsible for branching/merging. You only committed stuff which was in great shape and passed all the tests, just like Fossil wants you now.
And there were manual source code copying, so much copying.
- You are writing a feature and got interrupted mid-work to work on something else - copy/tar those files and restore from svn (you could also do a second checkout, but that destroys your cache).
- Want to send incomplete changes to friend? run "diff" and send them the patch by email, or place that patch file on shared disk.
- Your check-in failed, you need to merge in in latest changes from master? better tar up your work in case you break stuff.
- Are you doing new feature and want to see if refactor will improve it? don't forget to make a copy of changed files in case it does not.
None of this is worth committing on master. Who would want to share an incomplete feature which does not build / does not pass unit tests? Or an pre-refactor version of code which does not work?
Turns out using "git" covers all those usecases, and that's why it's the greatest thing. Fun fact: we've started using git in our team using git-svn, without central git server - we had mutable and shareable commits until the last moment, when we pushed it to central svn server.
IMHO, if you only want to record the final path code takes, and you plan to use "cp", "tar" and "patch" for throw-away work, then you might as well use a "releases" directory on FTP with timestamped archives. Why bother with VCS then?
And this highlights my frustration. I don’t want to have this debate. The tool should allow its operator to set whatever level of strictness or purity they want for their project. Fossil already offers a million settings. Add another and make me turn on “dangerously-unsafe-rebase” to get the feature if need be.
What you're wanting is against their philosophy. However, there is removal via shunning. There's also the query langauge to control the view. So, there's everything you need to do what you want.
Obviously that's going to take some figuring out for queries and aliases. But it seems doable to me.
Awkward, yes, but doable. AFAICT, they've provided a way to do things that go against their philosophy should anyone be inclined.
Suppose a secret like some personally identifying information was recently leaked into the main branch. You are legally required to scrub it. How do you fix it?
Ideally a repo needs to reflect the state of every event that happened. Practically there are edge cases when it's just best to rewrite history.
For me, I know backend development really well, and HTML/CSS passably. HTMX has been much lower friction for me than learning JS frameworks, which tbh I didn't really enjoy, and they were constantly changing. But now, I had mostly leave the JS to Claude, and the HTMX draw has diminished a bit.
I don’t feel like the learning curve has shifted dramatically for mainstream development. Besides generics—which tend to not show up that often in app code even now—I can’t think of any substantial language change since I Iearned it in 2014. (Well, modules, but that’s more tooling.) Where I do see the shock is jumping to def of a std lib function and landing in indecipherable type soup.
The whole "Stage this hunk [y,n,q,a,d,k,K,j,J,g,/,e,p,P,?]?" line is pretty intimidating, but I urge anyone who still wants to understand git and be able to (themselves) use it effectively, to do "?" when you see it, read through what each action does and forcefully try them out to see what they do, in some low stakes project. Ends up being a super quick way of staging a whole bunch of work and avoiding staging other, but it's pretty weird at first glance.
it's not as easy as you said.
it can be tricky and complicated to use edit mode.
I usually use it, but still often don't understand - will this edit succeed or why it is failed.
I've lapsed my subscription because it has, in my opinion, gotten a bit too clickbait-y and many of the articles are sort of thin rehashes of already covered material. It is still better than most, but also fairly pricy.
Tone/style bit aside, a real problem is length. Scroll waaay down and look at most older updates and see how brief and too-the-point they were. Often they look rushed, some essential links, and that’s it. Fine by me! That’s the real state of things… people usually don’t want to write bc it’s a lot of effort.
I see the same phenomenon at work. A year ago I’d read your two-sentence daily update in slack, all riddled with the quirks and oddities that made it yours. Today when I see the page of headings and emojis describing the couple things you did yesterday, I wince because now I’m the one who has to sift through the fluff to get to the point.
I never did get used to the Chezmoi workflow. `chezmoi edit` never became muscle memory, and I was constant finding myself resolving diffs and what not.
BeyondCompare 2-way merge usually resolves everything automatically, and it's set up as the default mergetool for me, so it's only a couple of clicks... But yeah, takes some muscle memory.
reply