Re: [PATCH 2/2] Add keyword unexpansion support to convert.c

Linus Torvalds [off-list ref] 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.

On Tue, 17 Apr 2007, Junio C Hamano wrote:

The use case the thread you are responding to assumes that you
do *not* have a preimage before the change.

Sure. However, see my other script to actually find the "closest version". 
It's pretty easy.

In fact, even if you don't know which file it is, we could easily first 
have a separate "try to guess filename" (based on the same kind of 
heurstics) and then dig deeper on that filename.

So I think there are better ways to get the same effect without embedding 
any information.

		Linus