Re: An alternate model for preparing partial commits

-- Stephen Sinclair wrote:

Of course developers need to be able to make bad-commits. If they can't, we quickly end up back in the "don't checkin" mentality of CVS. I want to be able to do bad-commits. Further, I recognize that even with the best of intentions bad-commits will enter the mainline. What I think is missing is a mechanism for re-summarizing a set of committs that does not rely on the fact that they've never been published. See my other email on "supercede"..

Consider a big public tree that is using bisect, but discovers that there is a bad commit in the mainline. I have no idea what you would do with current git to fix this. However, if I could pick two endpoints and "supercede" them, I would have a bunch of options:

- I could supercede 2-commits with 1, effectively making the bad-commit
disappear in the linear history. Users who already have the history, however,
would be unaffected, because the start/end endpoints are the same.

- I could supercede 2-commits with two different commits, one that makes the
test pass correctly, and one that trues-it-up with the next patch, that somehow
made all the tests pass correctly again. (possibly by hoisting a diff out of
the 2nd commit that actually fixed the first issue)

While repairing an old test build problem may seem like an infrequent issue, this mechanism has a much more frequent and more important benefit... which is that people can share changes and then later rebase them -- and others who have a copy of that branch will receive automatic merge/rebase support. (assuming there are not reasons for conflict)