Thread (1 message) 1 message, 1 author, 2016-06-15

Re: update-index --index-info producing spurious submodule commits

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:51

Junio C Hamano [off-list ref] writes:
As "update-index --index-info" predates "submodule" by a few years or
more, I wouldn't be surprised if the code didn't notice it was fed a wrong
input and produced nonsensical result that happened to be a commit.

The command could just instead barf, saying the input is wrong, but the
option was so low-level that it was deliberately written to accept and
store anything you throw at it --- even when it is nonsensical for the
version of plumbing, later updates to the data structure might have made
it making sense, which was the way to ease development of the system.
The second paragraph needs a bit of clarification. What I meant to say was
that the --index-info and its command line cousin --cacheinfo interfaces
are designed to be used like using a hex editor on the disk block device
to modify the file system in a random way, and just like a hex editor does
not prevent you from writing a data to the disk that is not understood or
misunderstood by the current filesystem implementations, ideally it should
allow you to put data that is beyond the current design of the index, so
that it can be used as a way to experiment while developing enhancements
to the index further. That in fact was how I experimented with updates to
the code to read from the index (in read-cache.c) in early days. Also they
do not even look at the object name they are given, and that is very much
deliberate---otherwise you cannot even stuff gitlinks in the index---and
in general, the less sanity-checks we do in that interface, the better off
we will be. After all we may someday start adding a tree entry in the
index for a reason unknown to us today.

I am all for documenting that today's index holds only regular blobs (mode
100644), executable blobs (mode 100755), symlink blobs (mode 120000), and
gitlinks (mode 160000), somewhere in the general part of the document not
specific to these options, and also documenting that the result of the
operation is undefined if anything outside the officially supported kinds
of input is fed to --index-info/--cacheinfo.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help