Junio C Hamano wrote:
> I somehow doubt it. Both index-pack and lost-found need to trace
> "object A depends on object B", but the similarity ends there.
You already responded about this in another side-thread, so the
following is mostly redundant. :) I think this message can still be
useful to future readers since it more explicitly goes through the
trade-offs.
The relevant similarity is that both index-pack and lost-found need to
inflate all commit, tag, and tree objects.
This is the same idea that led to the introduction of "git index-pack
--strict".
[...]
> I am not quite sure if that is an advantage, though. The second
> message proposes that the lost-found computation to be done by the
> client using *.pack, but any client, given the same *.pack, will
> compute the same result, so if the result is computed on the server
> side just once when the *.pack is prepared and downloaded to the
> client, it would give us a better overall resource utilization. And
> in essence, that was what the *.info file in the first message was.
Advantages of not providing the list of roots:
1. only need one round-trip to serve the packfile as-is
2. less data sent over the wire (not important unless the list of roots
is long)
3. can be enabled on the server for existing repositories without an
extra step of generating .info files
Advantage of providing the list of roots:
- speedup because the client does not have to compute the list of roots
For a client that is already iterating over all objects and inspecting
FLAG_LINK, the advantage (3) seems compelling enough to prefer the
protocol that doesn't sent a list of roots.
Except when people pass --depth, "git clone" sets
'check_self_contained_and_connected = 1'. That means clients that
already iterate over all objects and inspect FLAG_LINK are the usual
case.
Thanks for your thoughtfulness,
Jonathan
--
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