Messages in this thread | | | Date | Tue, 30 Jul 2002 14:46:12 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch] Input cleanups for 2.5.29 [2/2] |
| |
On Tue, 30 Jul 2002, Vojtech Pavlik wrote: > > Now the question remaining is how to fix that? You can just skip the > patch. I've tried a 'bk undo', but that complains about unmerged leaves > in that case (though really nothing depends on those changes). Or should > I just make another cset on top of all the previous?
Ugh. there's a few things you can do
- I often actually do a "bk undo -axxx" and then just re-do the parts I want to re-do.
NOTE! This only works if you haven't already had people pull from your repository (or you'll need to ask them to do the "bk undo" as well).
- You can reverse the cset, which means that it's still there, but there is also a cset that says "undo that other cset". I prefer to not pull those kinds of undo's, but they do happen, and I occasionally do them myself. I try to avoid it, but it's very useful for debugging ("does that problem go away if I undo just that one cset?"), and sometimes it _is_ the sanest way to go.
So do "bk cset -xA.BBB"
- in this case, maybe just adding a new cset is the proper thing. Especially as reversing the cset doesn't actually get you where you want anyway, since you'd still have to do the "unsigned short" -> "u16" translation as yet another cset.
I only get upset if the tree looks _really_ cluttered, in which case I may ask you to re-do it (that's happened once with the reiserfs tree).
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |