Re: Mercurial 0.4b vs git patchbomb benchmark

  > Your example had Joe reviewing a signed diff, and then applying changes
  > from a tree that "supposedly" had the diff applied correctly, but may
  > have been corrupted. If the tree was not an accurate representation of
  > applying the diff, then the changes Joe applied to his tree will be
  > different than those that he reviewed.

That's right.   I'm saying that Joe needn't rely on the tree at all since
he should be having his tools verify its contents anyway.  Given that, 
he may as well have his tools *generate* the tree.  Having generated the tree,
it's gravy to then verify that it matches the tree the submitter thought he
was sending -- that's a *secondary* checksum where `git' currently uses
it as primary.


  > My example had Joe downloading a remote signed tree, reviewing the changes
  > locally between his own trusted tree and the remote tree, 

In the real world, that "review" step is the weak link.  When it goes
wrong, the first step is to make sure we are reviewing a tree everyone
involved *intended* -- and it's only with signed diffs adding up to
that tree that we get there.

-t
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html