Hacker News Reader

Comment by xeeeeeeeeeeenu | Hacker News Reader

The author of Fossil considers rebase harmful, and because of that, it wasn't implemented[1].

I'm not a fan of that decision. I don't want to live with my mistakes forever, especially on local branches.

[1] - https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md

Rebase is may favourite part of git. Committing a small bug fix as you go and then plucking it out and moving it to the front of the queue is just so handy and avoids all those "Implement feature X, and a few bug fixes too, lol" commits.

Not to mention a stream of WIP commits that mean at any point I can diff the mess I've made in my editor to when it was last working (or any other time). Often that's enough to reveal the problem. If you don't commit often enough, you can't do that, but if you can't rebase, the history is full of junk that should be collapsed before going public.

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.

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.

Does it have something like git amend for local branches? That will at least allow the latest commit to be changed.

In case anyone is confused, git amend can amend the changes, not just the commit message. I didn't notice this for a while, and finally got around to reading about how it works. https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

Fossil's amend command covers a wide set of commit attributes. This can be applied not only to the latest commit, but also at any historical point. Looks like it's implemented as a new special commit with some internal logic which overrides the original commit's metadata. This is actually done without altering the historical record of the original commit; it's transparent on the log/timeline, but the amend event entry can also be made visible.

Very clever way of letting user fix some attribution mistakes/typos, yet not mangle the original commit.

However, for amending the actual file changes, like it could be done with git --amend, Fossil requires another proper commit; for historical amends, the new commit has to be put onto a new branch.

Fossil-scm website has a detailed help section for all commands, including the amend.

Fossil has private branches which can serve the same purpose. When you merge a private branch it looks just a single commit, similar to a squashed merge.

That throws out the baby with the bathwater. I frequently merge feature branches with changes still split into a small number of commits, each representing an atomic step associated with the overall change.

That's not true. In fossil when you have multiple cherry-picks in a single merge, you can still get the hashes directly.

https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#...

Merges should be considered harmful and disabled by default.

They ruin history, get in the way of bisect, may not be reproducible, etc, etc.

Sometimes they may be used but more likely as a superuser operation

GitHub's button to update the current branch annoys me. It creates a merge commit back from the main branch to the feature branch. I would rather it back up the current branch and rebase it or something, or just let me do it the right way manually (rebase and force push).

You can set on the repository if you want it to rebase instead[0]

[0]: https://docs.github.com/en/pull-requests/collaborating-with-...

I know about that but don't know if it works for updating a branch before merging it. I'll have to try changing it to that setting.

Annoyingly this always re-writes commits (i.e. never fast-forwards), which means that if you have branches based on the branch you're merging they will need to be rebased, and git will complain about deleting the branch because it looks like it's unmerged.

I've never had an issue with merges in 10 years of using git.

Reply on news.ycombinator.com