Re: [PATCH 000/141] V4L/DVB updates part 1
From: Linus Torvalds
Date: Wed Mar 22 2006 - 22:29:03 EST
On Wed, 22 Mar 2006, Junio C Hamano wrote:
> I am curious how you found it initially. After you pulled but
> before you did further work on top of the updated HEAD, I am
> suspecting that there is some sanity check done by you to detect
> that you pulled a faulty tree and decide to discard the merge.
I tend to have a two-level safety check. The first is that I just check
the diffstat of the result of the pull (I realize that people hate the
fact that the diffstat is often the most expensive part of a pull, but to
me it's one of the more important things).
So I check the diffstat not only for sanity (if somebody asks me to pull a
tree that is ARM-specific, the diffstat should only show ARM files
changing), but also tend to match it up against what the "please pull"
email _claimed_ the diffstat should look like
This is why I ask people to include the diffstat and shortlog in their
"please pull" messages: not only does it mean that I get a high-level idea
of what the pull is going to do even before I do it, it also means that if
my end result is different from the claimed one, it's likely some
confusion with the tree (or I pulled the wrong branch because I didn't
notice that it wasn't the main one).
This first-level safety check generally catches any serious mistakes, and
it's helped me catch cases where the other end did something really stupid
However, in this case, the diffstat didn't actually show anything strange,
because the problem was a bogus merge from my own tree, which obviously
thus merged perfectly and caused no actual _data_ changes as far as the
end result was concerned.
So this one was caught by the fact that I'm just fairly anal about the
history being sensible (as the ACPI people may remember ;), so I usually
after pulling. That gives me a nice overview of what the heck the history
looks like, and is what caught this one. I don't _always_ do it, and
especially with people who have been merging with me since BK days I
sometimes don't bother with this thing, but I do it most of the time.
Finally, I do a "git-fsck-cache" after pretty much every "git pull"
sequence just because I'm anal.
Basically, if the history looks sane, and the diffstat doesn't raise any
red flags, I'm then usually happy. Of course, since I only really pull
from people that I trust _anyway_, none of this is about really trying to
find "bad stuff" - it's more about
(a) stupid mistakes. Especially early on, this (and some extra checks,
like doing "git-whatchanged ORIG_HEAD.." - which is just a much
easier way to scan the commits in more detail without actually seeing
the full patches than gitk) caught a number of cases where the other
end had simply done a mistake. We had a number of those. Happily,
people have clearly gotten more used to git, and I also think that
git simply doesn't allow some of those mistakes any more.
(b) keeping the history clean. I _hate_ having an unreadable history. The
"whole project" history inevitably gets very complex after a while,
but I'm personally convinced that as long as the history makes sense
in the "small picture" (ie the "gitk ORIG_HEAD.." kind of thing), it
just helps the big picture.
So for _me_, I don't worry so much about the actual patch itself. I seldom
have the time to look closely and the actual changed lines, although the
merges with Andrew I tend to actually check those (partly because they
aren't git merges and so I actually have to check the emails one by one
_anyway_, but partly because unlike the git merges, Andrew's stuff tends
to be all over the place and often to very core stuff, so I need to be
more aware of them).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/