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

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 http://lwn.net/Articles/328436/ http://lwn.net/Articles/328436/ (see also http://lwn.net/Articles/328438/ 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. :)