So, the answer is: if others have actually pulled, it's simply not
possible.
There simply is no way to undo history that isn't local any more. You just
*have* to revert, or you need to find every single person that pulled
(directly or indirectly) and ask them to undo all the work they did on top
of your bad commit.
This is not git-related, btw. That's just how the world works. It's a bit
like the internet - if you said something stupid on #IRC and it made it to
bash.org, there's not a whole lot you can do to "undo" your stupidity. You
can only hope to do better in the future and assume people forget.
Just delay pushing out. There really is _zero_ downside to this. None at
all. There are only upsides.
Umm. Git doesn't complain about whitespace _except_ when applying patches.
So if you don't rebase his work, you'll never see the whitespace warnings
either!
Of course, we'd probably wish that Jeff cared about the whitespace
warnings and pushed back on them, but the fact is, that warning isn't
meant for you - because by the time you pull Jeff's tree, it's simply not
your issue any more. Jeff already applied it. Either he's your trusted
lietenant or he's not.
Quite frankly, to me it sounds like you're not ready to "let go" and trust
the people under you. Trust me, it's worth it. It's why your life is easy:
I have let go and I trust you.
Also, I'd *much* rather have a few problems in the tree than have people
screw up history in order to hide them. Sure, we want to keep things
bisectable, but quite frankly, if you do a reasonable job and compile the
kernel before you push out, it will be "mostly bisectable".
And yes, mistakes happen. Mistakes will *always* happen. It's ok. Relax.
Let me put it another way: You're _both_ going to be *much* better off
pushing back on Jeff, telling him that "I can't pull from you because your
tree is ugly and doesn't compile", than taking his tree and rebasing it.
Remember? I used to do that all the time. I berated the ACPI people for
creating monster trees that were horrible and contained fifteen merges and
two real commits. I didn't try to clean it up for them, I just told them
what the problem was, and you know what? The ACPI tree is one of the
cleanest ones out there now!
So in short:
- clean trees and bisectability are all wonderful things. No doubt about
that at all.
- but if getting there means that you lose a lot of _other_ wonderful
things (like being able to trust history, and the people being under
your watchful eyes havign to deal with you re-writing their trees),
we'd be much better off taking the occasional commit that fixes things
up _after_ the fact rather than before!
- and you actually can help fix your issues by doing some simple things
*before* pushing out, rather than push out immediately. IOW, do your
whitespace sanity fixes, your compile checks etc early, and don't push
out until after you've done them.
Hmm?
Linus
--
