Re: Mercurial 0.4b vs git patchbomb benchmark

[Tom Lord]

   From: Linus Torvalds <torvalds@xxxxxxxx>

   On Fri, 29 Apr 2005, Tom Lord wrote:
   >
   > 	1) the ancestry of their modified tree
   > 
   > 	2) the complete contents of their modified tree
   > 
   > 	3) input data for a patching program (let's call it "PATCH")
   > 	   which, at the very least, satisfies the equation:
   > 
   > 		MOD_TREE = PATCH (this_diff, ORIG_TREE)
   > 
   > On the other hand, signing documents which represent a {(1),(3)} pair
   > with robust accuracy is, in most cases, much much less expensive than
   > signing {(1),(2)} pairs with robust accuracy. 

   Not so.

   It may be less expensive in your world, but that's the whole point of git: 
   it's _not_ less expensive in the git world. 

   In the git world, 1 and 2 aren't even separate things. They go together. 
   And you just sign it. End of story. It's so cheap to sign that it's not 
   even funny.

The confusion here is that you are talking about computational complexity
while I am talking about complexity measured in hours of labor.

You are assuming that the programmer generating the signature blindly 
trusts the tool to generate the signed document accurately.   I am 
saying that it should be tractable for human beings to read the documents
they are going to sign.


   More importantly, signing 3 is meaningless. 3 only makes sense with a 
   known starting point. You should never sign a patch without also saying 
   what you're patching. 

I advocated signing a {(1),(3)} pair, not simply (3).

   And once you do that, 1+2 and 1+3 are _exactly_ the same thing.

I already spoke to that.

   And since git always works on the 1+2 level, it would be inexcusably
   stupid to sign anything but that. 3 doesn't even exist per se, although 
   it's obviously fully defined by 1+2.

   So I don't see your point. You complain about git signing, but you 
   complain on grounds that do not _exist_ in git, and then your alternative 
   (1+3) which is senseless in a git world doesn't actually end up being 
   anything really different - just more expensive.

I'm not sure what to suggest other than go back and read more carefully.

-t

-
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/