3 ms·
I think it's for the perfect people, who never have to amend commits, never commit to the wrong branch, only work on one branch at a time.. basically closer to
by theamk 3y ago
I think it's for the perfect people, who never have to amend commits, never commit to the wrong branch, only work on one branch at a time.. basically closer to SVN than GIT.
If all your git interaction is via "git commit" with occasional "git checkout", then fossil could be an interesting option - it has web frontend with stuff like wiki etc.. built in.
If you start working on "temp1" branch, make dozens of no-message commits and only then carefully make nice-looking PRs out of them, then fossil isn't for you. If you ever used force push to fix mistakes before anyone noticed.. then fossil isn't for you either.
- zie 3y agoYou actually can do most(all?) of this in Fossil, it just puts a big frowny face next to it, and highly encourages you to not change history, for hopefully obvious reasons. Some of us think actual history is more important than a persons idealized representation of the past.
- isr 3y ago??? You could just make a temp2 branch, from master at the same branching point as temp1, and then periodically create your astonishingly beautiful commits from the horridly messy temp1, to temp2. And then merge temp2 to master, when you want. The only "sin" fossil commits here is that temp1 is still there, if you want to see what you ACTUALLY did (yes, I fully accept that your beautifully crafted commits are totally bug-free). And here's the real kicker: the fossil ui is easily customizable so that certain branches (eg: "tmp-...") can be hidden from the timeline view, so they don't get in the way. I believe the sqlite team (inc DRH) have hundreds of "tmp" branches, whose only purpose is "messy commits, clean up later" (yup, you can refuse the same branch name as many times as you like, easier for auto-hiding.