>>Do not hint deprecation and future removal with "still" and "for >>now", before seeing a concensus that it should be deprecated and >>removed. Agree. Will remove. >>The new thing, <recursively>, deserves some explanation. What are >>the acceptable values (yes/no? spatial/time/both? infinitely/limited?) >>and what do these values mean? More expanation. I think over about <recursively> and consider to remove it in next patch because offer a pack only contains commit or tree object individually may not make much sense, so <recursively> will remove(as default on tree and commit object) in next patch. >>Why is this limited to only <blob> and <commit>? Will support tree but not tag(maybe furture work) in next patch. >>There isn't a fundamental reason why I shouldn't be able to say >>"v2.32.0" instead of ebf3c04b262aa27fbb97f8a0156c2347fecafafb (or >>"v2.32.0~0") to say "I want anything reachable from v2.32.0 (in >>other words, that version and everything before it)", is there? >>For that matter, "everything reachable from this tree object" may >>also be a reasonable way to specify which set of objects are >>offloaded to an out-of-band URI. Agree. Will provide more detailed instuctions in next patch. Thank you.
