On Sun, 15 Apr 2007, Robin H. Johnson wrote: > The checksum file (named Manifest) we are talking about is for a single > subdirectory, and is signed as proof that it was not modified between > the developer and submission to the tree. So the process has to be: 1. Developer commits changes to files. 2. Checksum utility finds the checksums of the files with IDs added where the master site updater will add them. 3. Developer signs checksums. 4. Developer commits checksums. 5. Developer pushes changes to master site. 6. Master site checks out files, adds IDs, and updates live tree. 7. End user fetches tree. 8. End user checks checksums, which match, because the master site and the developer checksum scripts agree on what the end user will see. The only difference is that developers working out of the version control have to generate the checksums with a tool that knows how the IDs will be added, and check the checksums with this tool as well, because working directories don't have IDs in them. Really, it's approximately the same as having the version control system do it, except that it's in the project-specific development tools instead of the version control system. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html