I very strongly disagree with this post. But I should be clear that I also strongly disagree with the statement 'always use rebase!'.
Merge and rebase are two similar but distinct ways to update a branch in git. They are both appropriate at different times. A very good guide to sensible merge/rebase policy can be found here
I use rebase regularly. I always work on branches other than master, i.e. task and feature branches. I never rebase branches that are shared with other developers - development to these shared public branches is always just adding new commits to a stable history. Merging is important but rebasing is a wonderful tool.
With respect to the issue of timestamps, I did not know this and am very glad to learn it, you do have a problem here. My position would be that I would rather throw out the timestamp chronology than abandon rebase. Typically in my experience bugs can, and usually are, tracked against a particular commit, which solves this problem. However, I appreciate that this won't always be the case, but throwing out rebase for this is a high price for a moderate reward IMHO. :)
The timestamp thing is a red herring. Git tracks CommitDate and AuthorDate separately. CommitDate gets updated by default in a rebase. Use 'git rebase --ignore-date' to also update AuthorDate, though I like having both pieces of information.
> since you most not rebase other peoples work, that means that you must
> never pull into a branch that isn't already in good shape. Because after
> you've done a merge, you can no longer rebase you[r] commits.
> Notice? Doing a "git pull" ends up being a synchronization point.
Merge and rebase are two similar but distinct ways to update a branch in git. They are both appropriate at different times. A very good guide to sensible merge/rebase policy can be found here
http://lwn.net/Articles/328436/
(see also http://lwn.net/Articles/328438/)
I use rebase regularly. I always work on branches other than master, i.e. task and feature branches. I never rebase branches that are shared with other developers - development to these shared public branches is always just adding new commits to a stable history. Merging is important but rebasing is a wonderful tool.
With respect to the issue of timestamps, I did not know this and am very glad to learn it, you do have a problem here. My position would be that I would rather throw out the timestamp chronology than abandon rebase. Typically in my experience bugs can, and usually are, tracked against a particular commit, which solves this problem. However, I appreciate that this won't always be the case, but throwing out rebase for this is a high price for a moderate reward IMHO. :)