The big contention among git users is whether to rebase or to merge changes [2][3] while iterating. I used to firmly believe that merging was the way to go and rebase was harmful. More recently, I have worked in some environments where I saw rebase used very effectively while iterating on changes and I relaxed my stance a lot. Now, I'm on the fence. I appreciate the strengths and weaknesses of both approaches. I waffle between the two depending on the situation, the tools being used, and I guess, to some extent, my mood. I think what git needs is something brand new that brings the two together and has all of the advantages of both approaches. Let me explain what I've got in mind... I've been calling this proposal `git replay` or `git replace` but I'd like to hear other suggestions for what to name it. It works like rebase except with one very important difference. Instead of orphaning the original commit, it keeps a pointer to it in the commit just like a `parent` entry but calls it `replaces` instead to distinguish it from regular history. In the resulting commit history, following `parent` pointers shows exactly the same history as if the commit had been rebased. Meanwhile, the history of iterating on the change itself is available by following `replaces` pointers. The new commit replaces the old one but keeps it around to record how the change evolved. The git history now has two dimensions. The first shows a cleaned up history where fix ups and code review feedback have been rolled into the original changes and changes can possibly be ordered in a nice linear progression that is much easier to understand. The second drills into the history of a change. There is no loss and you don't change history in a way that will cause problems for others who have the older commits. Replay handles collaboration between multiple authors on a single change. This is difficult and prone to accidental loss when using rebase and it results in a complex history when done with merge. With replay, collaborators could merge while collaborating on a single change and a record of each one's contributions can be preserved. Attempting this level of collaboration caused me many headaches when I worked with the gerrit workflow (which in many ways, I like a lot). I blogged about this proposal earlier this year when I first thought of it [1]. I got busy and didn't think about it for a while. Now with a little time off of work, I've come back to revisit it. The blog entry has a few examples showing how it works and how the history will look in a few examples. Take a look. Various git commands will have to learn how to handle this kind of history. For example, things like fetch, push, gc, and others that move history around and clean out orphaned history should treat anything reachable through `replaces` pointers as precious. Log and related history commands may need new switches to traverse the history differently in different situations. Bisect is a interesting one. I tend to think that bisect should prefer the regular commit history but have the ability to drill into the change history if necessary. In my opinion, this proposal would bring together rebase and merge in a powerful way and could end the contention. Thanks for your consideration. Carl Baldwin [1] http://blog.episodicgenius.com/post/merge-or-rebase--neither/ [2] https://git-scm.com/book/en/v2/Git-Branching-Rebasing [3] http://changelog.complete.org/archives/586-rebase-considered-harmful
