On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin <carl@xxxxxxxxxxxxx> wrote: > Anyway, now I am compelled to use github which is also a fine tool and I > appreciate all of the work that has gone into it. About 80% of the time, > I rebase and force push to my branch to update a pull request. I've come > to like the end product of the rebase workflow. However, github doesn't > excel at this approach. For one, it doesn't preserve older revisions > which were already reviewed which makes it is difficult for reviewers to > pick up where they left off the last time. If it preserved them, as > gerrit does, the reviewer can compare a new revision with the most > recent older revision they reviewed to see just what has been addressed > since then. A bit of a tangent here, but a thought I didn't wanna lose: In the general case where a patch was rebased and the original parent pointer was changed, it is actually quite hard to show a diff of what changed between versions. The best I've found is to do something like a 4-way --cc merge diff, which mostly works, but has a few awkward cases, and ends up usually showing double ++ and -- notation. Just something I've thought about a fair bit, trying to come up with some good way to show "what changed between A1 and A2, but ignore all changes between parent P1 and P2 which you don't care that much about in this context. Thanks, Jake
