Hacker News Reader

Yeah interactive rebasing is such a fundamental part of how I work with git, that's a total deal breaker. It's how you both "commit early and often" and leave a logical chain of commits behind in the end.

Without the ability to rewrite local history, you're either not commiting often (risky) or leaving long streams of poorly documented "work-in-progress" commits in the main project history.

View on HN

If I undestand it correctly, Fossil does not support a reordering of commits. However, some of rebase effects could be achieved by using so called private branches (these do not get pushed to remote). The desired sequence could be created by cherrypicking between private branches, then the result merged onto the trunk or whatever normal branch and pushed to remote.

For simple squash of WIP, the private branch works quite naturally, and simply merges onto the normal branch. For more involved reordering, it would be too cumbersome to be practical.

However, Fossil philosophy advocates a factual approach to commit history, unlike a 'maintained' approach that's so widely expected by Git-based workflows, and which calls for the use of rebase.

Reply on news.ycombinator.com