Re: [PATCH 0/3] fix "diff --raw" on the work tree side

[Junio C Hamano <gitster@pobox.com>]

"Ping Yin" <pkufranky@gmail.com> writes:

> On 3/3/08, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> I do not think re-introducing the inconsistency like the third one does is
>> a palatable option.
>>
>> Wouldn't grabbing (cd $submodule && git rev-parse HEAD) yourself be more
>> portable across git before and after the bugfix of "git diff --raw"?
>
> OK, i will parse it myself

Just to clarify, I am somewhat torn on [3/3].

We can certainly re-introduce the special casing for submodule across diff
family consistently, but the rationale for doing that would be "The real
object name is very cheaply available in that case so why not show it."

That line of thinking would lead to re-hashing of symbolic link blobs as I
hinted in the message, but then it would also mean we would show
inconsistent output between a symlink that points at foo.c and a regular
file whose content is foo.c (without the trailing LF), the latter of which
would still show 0{40}, and we will eventually end up saying "Let's
re-hash small regular file blobs."

That would lead to inconsistencies between smaller and larger regular file
blobs, and the line between them is drawn at an arbitrary size limit.  The
logical conclusion of this would be to re-hash everything when showing
"diff --raw" (and "diff-anything --raw").

Which may turn out not to be such a bad thing after all, and we might even
end up doing exactly that in future releases, although I highly doubt it.
In any case, such a huge semantics change takes time to get right.
People's scripts in the wild know 0{40} with non 0 mode in the raw format
means it refers to an entity in the work tree (which is a correct thing to
assume), but the convention has been used for the entire lifetime of git
and they can (arguably incorrectly) be assuming that the inverse is also
true (i.e. work tree entity is represented as 0{40} with non 0 mode).

And the point is that "submodule summary" can be useful without waiting
for the conclusion of the above confusion caused by the can of worms [3/3]
opens.  If we decide to always show the real object name for work tree
entities in the future, we might want to update the implementation of
"submodule summary" to _take advantage of it_, but by starting the new
feature not to depend on the current misbehaviour, we can try it out much
earlier.