Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > Besides, if you actually have the file, you can trivially get the SHA1 > _without_ embedding it into the file. Just do > > (echo -e -n "blob <size>\0" ; cat file) | sha1sum > > where "size" is just the size in bytes of the file. > > So embedding the SHA1 doesn't actually buy you anything: every blob BY > DEFINITION has their SHA1 embedded into them. > > In fact, embedding the SHA1 (or doing any other modifications) just makes > it harder to do this, since then you have to filter it out again. The use case the thread you are responding to assumes that you do *not* have a preimage before the change. You give a file out, somebody says "here is my updated version" and returns the whole file. You may recognize, from the contents, which path the file was taken from, but you may not know which revision to diff against, as the "update version" was not sent to you along with the version before he started updating. In my day job, I made a protocol, with a diff-challenged person in our Japanese subsidiary, for him to send *both* preimage and postimage of his changes when sending updates to me, and that has worked reasonably well without embedded ID. I can always do a file-level 3-way merge to forward port his change to whatever version I am working on. But if it is not an option to insist getting the preimage back, embedded blob ID would be one way to help that exchange. - 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