4 ms·
Yes, the interface is bad. But the paradigm also is: - it's made for multiple remote first (e.g: manual syncing is assumed by everything) despite the fact mos
by BiteCode_dev 4y ago
Yes, the interface is bad.
But the paradigm also is:
- it's made for multiple remote first (e.g: manual syncing is assumed by everything) despite the fact most projects have one
- it forces you to craft your commit index to commit instead of letting you commit all changes by default, and optionally craft things
- rebase exist, and is used a lot
- you have to chose between easy merge and a clean history
- it's hard to get a lock, a big file, a ticket or a todo list in sync in this repo. It's not made for that at all, and requires additional services or apps.
Fossil seems to fix all those.
- charrondev 4y ago- you have to chose between easy merge and a clean history I will note that at least with GitHub we’ve been using squash merges for a couples years on a pretty large project and it’s solved this for us. The devs that want a clean history (like me the project lead). Bisecting is very easy, every commit references a Jira ticket ticket. People that want to land multiple patches with multiple messages can make multiple pull requests. If you think the changeset is so distinct that I don’t want it to be one commit in a bisect, each changeset deserves its own review.