5 ms·

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 mist

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 https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md

thriftwy 5y ago
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
- benatkin 5y ago
  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).
  - no_wizard 5y ago
    You can set on the repository if you want it to rebase instead[0] [0]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges https://docs.github.com/en/pull-requests/collaborating-with-...
    - benatkin 5y ago
      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.
    - tomn 5y ago
      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.
- secondcoming 5y ago
  I've never had an issue with merges in 10 years of using git.
deleted 5y ago
[deleted]
- deleted 5y ago
  [deleted]
mb7733 5y ago
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.
- zoomablemind 5y ago
  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.
adhesive_wombat 5y ago
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.
benatkin 5y ago
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 https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
- zoomablemind 5y ago
  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.
rubyist5eva 5y ago
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.
- ycombobreaker 5y ago
  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.
  - geocar 5y ago
    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#testing https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#...

thriftwy 5y ago

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

benatkin 5y ago
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).
- no_wizard 5y ago
  You can set on the repository if you want it to rebase instead[0] [0]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges https://docs.github.com/en/pull-requests/collaborating-with-...
  - benatkin 5y ago
    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.
  - tomn 5y ago
    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.
secondcoming 5y ago
I've never had an issue with merges in 10 years of using git.

deleted 5y ago

[deleted]

deleted 5y ago
[deleted]

mb7733 5y ago

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.

zoomablemind 5y ago
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.

adhesive_wombat 5y ago

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.

benatkin 5y ago

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 https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

zoomablemind 5y ago
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.

rubyist5eva 5y ago

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.

ycombobreaker 5y ago
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.
- geocar 5y ago
  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#testing https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#...