Re: [PATCH 000/141] V4L/DVB updates part 1

[Linus Torvalds <torvalds@osdl.org>]

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 
by mistake. 

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 
also do

	gitk ORIG_HEAD..

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).

			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/