back
3 comments
Well, I need something where I store temporary files. Like right now, I am in the middle of prototyping major new functionality. It is huge, it is ugly (still) and it touches a half dozen of major subsystem.

It is a huge blob of changes. When it will be ready, I'd have to split it to maybe 6 to 8 commits, with well written commit messages. But I cannot do this yet -- for all that I know, I'll find out my design was bad, and I'll have to change those things tomorrow.

So the question is: what do I do with it?

In the old days, I had a VCS which could not change history (SVN). So I'd keep multiple worktrees and back them up manually ("project-2009-12-03.tar.gz", "file1.cc.before-refactor") and so on. The data would be lost sometimes. It was a pain generally.

Now, I have a git branch. It has commit messages like "fix crash in Foo()", "what if we used trie?", "oops forgot to update Bar to match" and so on. They should never see the light of day, and they won't -- they'll get re-made into different commits later. And git will help me to make sure the changes are not lost.

It looks like with the fossil, I should be going back to multiple worktrees and manual backups. I don't understand why would one want to do so.

With Fossil you could create many private branches off your feature branch with your experiments, and merge them into your feature branch when you're satisfied with that experiment.
that's the thing -- I'll be making 6-8 different branches out of that experimental branch.

In rebase world, I have a cycle of "cherry-pick a few changes, get them into master, rebase experimental so it gets smaller; repeat until nothing is left of experimental"

In permanent world, I guess I have two worktrees and copy files one-by-one, manually?

Seems like you should be able to write a 'rebase' tool that just does a sequential cherry-pick...
That's git's rebase with --onto and --interactive flags, I already use it and it is great.

The question is, why would people give this up and move to Fossil?

Why can't we have both?

It seems like both "an immutable view of what happened" and "a crafted narrative of feature changes, bug fixes and releases" are useful. Its ridiculous that I'm expected to pick one. Git and fossil should raise their game.

(Yes; git's tooling supports either approach, but not both at the same time. A better tool would let me avoid making this tradeoff at all.)

I'm saying rebase --onto is doable in Fossil. Whether it's built-in is another question.
You can. That is certainly a possible axiom as evidenced by fossil and some others, but as evidenced by git and common usage it is not necessarily "axiom 0" for all possible VCS's.

Unless you want to get really semantic in which case, sure "history" can't be changed, but "recorded history" certainly can.

That's a way for you to live your life by and Fossil will work for you.

I don't use that axiom, rampantly alter history all the time, and Fossil is not for me.

I'm glad that person mentioned it.