On Wed, Nov 06, 2013 at 02:25:50PM -0800, Junio C Hamano wrote:
> > Support in the code isn't always enough. The particular case that
> > brought this on is one where the index-pack implementation can deal with
> > thin packs just fine.
> >
> > This particular service takes the pack which the client sent and does
> > post-processing on it to store it elsewhere. During the receive-pack
> > equivalent, there is no git object db that it can query for the missing
> > base objects. I realise this is pretty a unusual situation.
>
> OK, I agree that it sounds quite niche-y, but it still is sensible.
> If a receiving end does not want to (this includes "it is incapable
> of doing so", but does not have to be limited to) complete a thin
> pack, the series will give it such an option in the longer term.
I wonder if we want to make the flag go in the opposite direction, then.
Right now we have no flag, and we assume the other side can handle a
thin pack. If we add a "thin" flag, then the timeline is roughly:
1. Receive-pack starts advertising "thin".
2. Send-pack cannot assume lack of "thin" means the other side cannot
handle "thin" (it might just be an older receive-pack), and keeps
sending thin packs.
[time passes]
3. Send-pack can safely assume that every server has learned "thin"
and can assume that lack of "thin" means the server does not want a
thin pack.
In other words, the benefit happens at step 3, and we do not get any
effect until some long assumption time passes.
If we instead introduced "no-thin", it is more like:
1. Receive-pack starts advertising "no-thin" (as dictated by
circumstances, as Carlos describes).
2. Send-pack which does not understand no-thin will ignore it and send
a thin pack. This is the same as now, and the same as step 2 above.
3. An upgraded send-pack will understand no-thin and do as the server
asks.
So an upgraded client and server can start cooperating immediately, and
we do not have to wait for the long assumption time to pass before
applying the second half.
It is tempting to think about a "thin" flag because that would be the
natural way to have implemented it from the very beginning. But it is
not the beginning, and the negative flag is the only way at this point
to say "if you understand this, please behave differently than we used
to" (because the status quo is "send a thin pack, whether I said it was
OK or not").
-Peff
--
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