From: Jeff Garzik <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 11:36:24 -0500
> Rebasing is low impact only if you don't have git downstream people. > Otherwise, you're just treating it as a useful quilt clone, really. Understood. One of the key operations that I'm interested in is removing things from the history. If I could do that using GIT without any side effects and in a way that really would remove it from the tree, I would do that in a heartbeat. At 1500 changesets, a merge conflict shows up about once every day or two as 2.6.N nears it's release into final as bug fixes trickle in. I find using GIT to fixup merge errors on a tree of that scale to be really painful. And it only fixes up the final result in a merge changeset. Just like we expect submitters to refresh their patches as things change upstream, we as developers should be able to refresh trees of changes we are maintaining for similar effect. This is all made difficult because GIT's commit IDs are tied to where they are in the tree, and thus are dependant upon the wholeness of parents and subsequently their parents. That's why it's hard to "just remove" something completely without rebasing the tree. Let me give you a good example, just yesterday I had to rebase my net-2.6 tree a few times. It's because I put a patch in there that the person said was OK but it broke the build. There is zero reason for me to push that tree to Linus with the bad commit and the revert, it's just noise and makes the tree harder for people to review. Now, to preserver your tree's history I simply reapplied the stuff I wanted then repulled your tree. But right now I have to redo the include/linux/rcupdate.h that's in there because it has a bug. I now want to rebase again to just kick out the existing rcupdate.h changeset, because I know of no alternative that really lets me get rid of the original bogus changeset. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/