Genuinely curious: Why do you need rebasing?
I'm mostly a mercurial person, where doing a rebase is highly discouraged and nontrivial. After all these years on mercurial, I've never found a need to do it. Why is it so popular amongst git users?
I'm mostly a mercurial person, where doing a rebase is highly discouraged and nontrivial. After all these years on mercurial, I've never found a need to do it. Why is it so popular amongst git users?
It's generally not seen as very good to send things upstream that conflict with existing changes, and including merges (from master, primarily) in upstream submissions is frowned upon.
When I was using mercurial, I ended up using the mq extension [1] to provide a similar work flow. I actually prefer mq's work flow to rebasing in git (simplifies some things when maintaining a set of changes), but the programs like that for git are lacking (I've tried guilt and quilt).
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.
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.
`hg rebase -s src -d dst`
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.
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.
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.
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.
hq's mq extension can do the same thing with a prettier UI but IMO much worse functionality.
Mostly to sort the code out before publication. People usually assume rebase as a tool for integration but forget how useful it is in the "local" development stage (ie. before pushing the code for the team).
Also, rewriting history (in the good sense of the term).
Git have some awesome approaches for minimizing the amount of semantically irrelevant commits in the repository (or plain garbage commits) that other VCSs lack. Mostly the possibility of having local branches (keeping them hidden away from everyone may be a plus in some cases) were a developer safely store that horrible-looking code everybody says they never write, go back, test, fix the code up, add test cases, fix indentation, documentation, etc. all in different commits and, then, rebase or squash-merge them in a self-contained, well-described and semantically split set of commits and then push them to the public repository in a way other team members can follow and understand.
For git, history is a tool for documenting the project -- and I love it.
I don't find that diamond branch development technique adds much in the way of useful information, so I tend to try to keep it linear.
Rebase may let me replay all of the other changes on top and save me lots of manual effort to get the patch so that it applies cleanly to trunk