"Ping Yin" <pkufranky@xxxxxxxxx> writes: > On 3/3/08, Junio C Hamano <gitster@xxxxxxxxx> 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. -- 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