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

From: Greg Troxel <gdt@ir.bbn.com>
Date: Aug 19, 2011, 00:27 UTC
Message-ID: <rmiliuq2qlg.fsf@fnord.ir.bbn.com>
In-Reply-To: <7vd3g272tk.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

> Greg Troxel <gdt@ir.bbn.com> writes:
>
>> git ls-tree HEAD foo
>> git ls-tree HEAD foo | git update-index --index-info
>
> This --index-info definitely looks wrong, if "foo" is a directory, as the
> entries in the index are supposed to be either blobs or commits.

In the man page for update-index in the --index-info section, what I'm doing seems to be covered by point 2, which specifically talks about output of ls-tree.

I realize the index is a data structure that has pairs of paths to blobs. But I also think of it as a representation of a tree object that would be referenced were one to commit (even if it isn't in that form yet). So I would argue that update-index with a tree should walk that tree and insert all the paths resulting from expansion into the index?

Show 5 quoted lines

> 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.

If what I'm doing is an abuse of update-index, do you or anyone else have a suggestion to make a directory in the index match a tree object? (I'm trying to use an index filter; it takes 11 hours to run filter-branch (5500 commits, 400K files in index, 800MB .git, ~2+GB working directory, tmpdir on NetBSD tmpfs (all in ram)).)

Thanks, Greg