Re: [git patches] 2.6.x net driver updates

[Linus Torvalds <torvalds@osdl.org>]

On Sat, 18 Jun 2005, Linus Torvalds wrote:
> 
> Your parent information was crap, meaning that when I pulled, I had to
> re-merge. In fact, I'm going to undo this pull entirely, because of this -
> it's simply _wrong_. You claim to have done a merge and indeed your "data"
> is merged, but your history is totally buggered because you didn't do the 
> proper parents.

Btw, this is serious. If you don't do proper parenting, you may have the
right _data_ in the tree, but because you lost sight of where that data
came from, all the commits leading up to that data (from the branch that
wasn't properly marked as a parent) are worthless and no longer reachable. 

In other words, it means that all the history leading up to the merge was
just lost, and you end up with just a magic "all these changes suddenly
appeared" patch that claims to be a merge, but is really just a big patch.

It also means that "git prune" will just delete the unreachable commits, 
since they are clearly not connected to anything any more. Also, any 
intermediate file contents (that were only reachable through those 
commits) are also unreachable and thus pruned. You literally end up with a 
situation where the "merge" is 100% equivalent to just taking the final 
patch, and applying it on top of the other head.

This may be the reason why you've had problems with "git prune". Your 
tree histories may be buggered, and you've lost the merges with me.

Quite frankly, I'd never have noticed, except:

 - because the history was buggered, the automated merge didn't find the 
   proper nearest parent, and thus it ended up finding a parent much 
   further back in history, which in turn meant that a trivial merge
   wasn't trivial any more, and I got a merge conflict on the
   drivers/net/r8169.c file.

 - actually looking at the history (with gitk, or by looking at how many 
   parents the commits have with "git log --pretty=raw") made it obvious 
   that your "merge" had only one parent.

This, btw, is one reason why I suggest against multiple branches, and run
git-fsck-cache --unreachable religiously. A bad merge with lost parents
normally causes unreachable commits, and that's a sure sign of trouble.

However, in your usage schenario, those commits are reachable in the
branch they originated in, and you mix it all up, so you'll never see the
warning signs.

I'm hoping my earlier pulls on your trees haven't resulted in these kinds 
of history losses before, and that this was the first time you did a merge 
and didn't specify the parents properly. Pls confirm..

		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/