-- Stephen Sinclair wrote: > However, having gotten used to the git way of things, I > personally don't see the problem with allowing > bad commits, as long as they are not pushed to public. 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) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
