4 ms·

If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits. Some repositories, like Rails have a lot of merge commits. Wh

If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits. Some repositories, like Rails have a lot of merge commits. Why should I have to read through them? Also, all kinds of failed tests may have been developed in a feature-branch during month-long development. Interactive rebasing lets you avoid that mess, I don't think it is that complicated. Mercurial uses the same underlying data structures, so I don't understand how rebasing can be more complicated on Mercurial than Git.

detaro 10y ago
> I don't understand how rebasing can be more complicated on Mercurial than Git. It's more complicated in the sense that there isn't a nice command for it. You still can do it by doing multiple lower-level steps, or installing an extension that makes it nicer.
- Siecje 10y ago
  You have to enable the rebase extension (comes with Mercurial) and it is just `hg rebase -s src -d dst`
BeetleB 10y ago
So let's say I branched off of master 3 months ago, and slowly developed the feature. Now if I rebase, will the commit history show all my local commits at the time they occurred (i.e. spread across 3 months)? Or will it show up as a single commit at the end? As for "reading through them", I usually use a GUI that shows the commit history, and it will show all the commits in a branch in, well, a branch. I can easily ignore them.
- jdmichal 10y ago
  Git actually maintains the following: Author and AuthorDate: These will not change during a rebase. Unless maybe you do an interactive rebase and edit the commit... I'm not 100% sure how those interact. Commit and CommitDate: These will change during a rebase, as a rebase is recreating the commit and that will be done with the current user and date.
- Rusky 10y ago
  It will show them at the time they occurred, with an additional notation for when the rebase command recreated them. On the other hand, it will not show any conflicts resolved during the rebase- it will just look like you knew all along what master was going to look like.
rbehrends 10y ago
> If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits. This is an artifact of Git. There are two principal solutions that do not require rebase. 1. Use Bzr-style hierarchical logs. This could in principle be used as a UI on top of Git. Here, merging rather than rebasing actually improves the readability of history. 2. Have fully labeled branches. This allows you to filter and visualize commit history based on branch membership. This is the approach traditionally used by most non-Git version control systems, but is not really viable in Git, because Git lacks the necessary meta information.

detaro 10y ago

> I don't understand how rebasing can be more complicated on Mercurial than Git. It's more complicated in the sense that there isn't a nice command for it. You still can do it by doing multiple lower-level steps, or installing an extension that makes it nicer.

Siecje 10y ago
You have to enable the rebase extension (comes with Mercurial) and it is just `hg rebase -s src -d dst`

BeetleB 10y ago

So let's say I branched off of master 3 months ago, and slowly developed the feature. Now if I rebase, will the commit history show all my local commits at the time they occurred (i.e. spread across 3 months)? Or will it show up as a single commit at the end? As for "reading through them", I usually use a GUI that shows the commit history, and it will show all the commits in a branch in, well, a branch. I can easily ignore them.

jdmichal 10y ago
Git actually maintains the following: Author and AuthorDate: These will not change during a rebase. Unless maybe you do an interactive rebase and edit the commit... I'm not 100% sure how those interact. Commit and CommitDate: These will change during a rebase, as a rebase is recreating the commit and that will be done with the current user and date.
Rusky 10y ago
It will show them at the time they occurred, with an additional notation for when the rebase command recreated them. On the other hand, it will not show any conflicts resolved during the rebase- it will just look like you knew all along what master was going to look like.

rbehrends 10y ago

> If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits. This is an artifact of Git. There are two principal solutions that do not require rebase. 1. Use Bzr-style hierarchical logs. This could in principle be used as a UI on top of Git. Here, merging rather than rebasing actually improves the readability of history. 2. Have fully labeled branches. This allows you to filter and visualize commit history based on branch membership. This is the approach traditionally used by most non-Git version control systems, but is not really viable in Git, because Git lacks the necessary meta information.