SZEDER Gábor <szeder....@gmail.com> writes:
>> git-gc - Cleanup unnecessary files and optimize the local repository
>>
>> Creating these indexes like the commit-graph falls under "optimize the
>> local repository",
>
> But it doesn't fall under "cleanup unnecessary files", which the
> commit-graph file is, since, strictly speaking, it's purely
> optimization.
I won't be actively engaged in this discussion soon, but I must say
that "git gc" doing "garbage collection" is merely an implementation
detail of optimizing the repository for further use. And from that
point of view, what needs to be updated is the synopsis of the
git-gc doc. It states "X and Y" above, but it actually is "Y by
doing X and other things".
I understand your "by definition there is no garbage immediately
after clone" position, and also I would understand if you find it
(perhaps philosophically) disturbing that "git clone" may give users
a suboptimal repository that immediately needs optimizing [*1*].
But that bridge was crossed long time ago ever since pack transfer
was invented. The data source sends only the pack data stream, and
the receiving end is responsible for spending cycles to build .idx
file. Theoretically, .pack should be all that is needed---you
should be able to locate any necessary object by parsing the .pack
file every time you open it, and .idx is mere optimization. You can
think of the .midx and graph files the same way.
I'd consider it a growing pain that these two recent inventions were
and are still built as a totally optional and separate features,
requiring completely separate full enumeration of objects in the
repository that needs to happen anyway when we build .idx out of the
received .pack.
I would not be surprised by a future in which the initial index-pack
that is responsible for receiving the incoming pack stream and
storing that in .pack file(s) while creating corresponding .idx
file(s) becomes also responsible for building .midx and graph files
in the same pass, or at least smaller number of passes. Once we
gain experience and confidence with these new auxiliary files, that
ought to happen naturally. And at that point, we won't be having
this discussion---we'd all happily run index-pack to receive the
pack data, because that is pretty much the fundamental requirement
to make use of the data.
[Footnote]
*1* Even without considering these recent invention of auxiliary
files, cloning from a sloppily packed server whose primary focus
is to avoid spending cycles by not computing better deltas will
give the cloner a suboptimal repository. If we truly want to
have an optimized repository ready to be used after cloning, we
should run an equivalent of "repack -a -d -f" immediately after
"git clone".
