One idea is to implement this using rebase --autosquash and --autostash options. But as with any rebase, we may hit conflicts, i.e. I have two CLs, and make an extra change, that I want to be applied in the first CL, but if this change depends (in terms of textual diffs) on the second CL.

When there's a conflict, rebase will stop and let the user fix the issue, then user calls git rebase --continue or git rebase --abort. It's not clear we want git change to leave the user in that state by default. Would we rather fail with something like: "couldn't apply change, use -f to fix conflicts"?

@cmarcelo I think the proposed change here is just that git change should complain if there are multiple outstanding commits. One may have arrived at this situation without realizing. I am resistant to reimplementing git-rebase in git-codereview.

@adg Yes, that's what I am asking for.

CL https://golang.org/cl/20049 mentions this issue.