Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> On Sat, 1 Mar 2008, Ping Yin wrote:
>
>> Strange things is this line
>> :160000 160000 34f279b1662a6bef6a8fdea1827bbdbd80f12444
>> 0000000000000000000000000000000000000000 M commonmake
>>
>> why mod is 160000 while sha1 is 0000...
>
> This indicates that a submodule (160000) was deleted (00000). It is
> easier not to handle a deletion as mode change...
Read the question again.
When you compare something with a work tree state, and when the work tree
state is dirty, we always show 0{40} to mean "it is dirty and we do not
know what the object name of that thing is, until you actuallly run
git-update-index (or git-add) it" (and at that point it would stop being
dirty). For blobs (be it a regular file or a symbolic link), this has an
advantage of not having to run hash-object to obtain the object name of an
object that would be created if you actually did git-add it.
When we check if it is dirty, we already do an lstat(2) and know the type
of it, so we can show the mode bits. So you will see 100644, 100755 or
120000 for blobs. Similarly for a submodule.
For a submodule, we could read the value from $sub/.git/HEAD, but it is
more consistent to show 0{40} on the work tree side (typically the right
hand side, unless you use -R).
--
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
