[v3,0/3] repack: pack everything into promisor packfile in partial repos

Message

Han Young Oct. 11, 2024, 8:24 a.m. UTC

Changes since v2:
- rebased to seen: 89afaf27d3 (Merge branch 'ak/typofixes' into seen, 2024-10-10)
- fixed t5710, "repack all" affects how the test repo is initialized
- use goto to skip normal repack

This series doesn't address the underlying problem with promisor objects,
but rather mitigates the "repack removes local objects" problem.
Until a satisfiable solution can be found[1], this would at least prevent
more promisor repos from becoming corrupted.

[1] https://lore.kernel.org/git/[e-mail]/

Han Young (3):
  repack: pack everything into packfile
  repack: adapt tests to repack changes
  partial-clone: update doc

 Documentation/technical/partial-clone.txt | 16 ++++--
 builtin/repack.c                          | 46 ++++++++++++---
 t/t0410-partial-clone.sh                  | 68 +----------------------
 t/t5616-partial-clone.sh                  |  9 +--
 t/t5710-promisor-remote-capability.sh     | 15 ++++-
 5 files changed, 65 insertions(+), 89 deletions(-)

Comments

Junio C Hamano Oct. 11, 2024, 6:18 p.m. UTC | #1

Han Young <[e-mail]> writes:

> Changes since v2:
> - rebased to seen: 89afaf27d3 (Merge branch 'ak/typofixes' into seen, 2024-10-10)

Please NEVER do this.  'seen' is as unstable and fluid as you can get.

Instead, base it on something that is well known and (supposedly)
stable, like v2.47.0 (or an updated tip of 'master'), and then
test (1) the topic by itself, (2) the result of trial merge of the
topic into 'next', and optionally (3) the same for 'seen'.

Thanks.

Junio C Hamano Oct. 11, 2024, 6:23 p.m. UTC | #2

Junio C Hamano <[e-mail]> writes:

> Han Young <[e-mail]> writes:
>
>> Changes since v2:
>> - rebased to seen: 89afaf27d3 (Merge branch 'ak/typofixes' into seen, 2024-10-10)
>
> Please NEVER do this.  'seen' is as unstable and fluid as you can get.
>
> Instead, base it on something that is well known and (supposedly)
> stable, like v2.47.0 (or an updated tip of 'master'), and then
> test (1) the topic by itself, (2) the result of trial merge of the
> topic into 'next', and optionally (3) the same for 'seen'.

If your topic really depends on what is done by other topics
in-flight, either in 'next' or 'seen', then prepare the base
by

 - picking a well known and stable base, e.g. v2.47.0

 - merge these ohter topics in-flight you depend on into the base
   you chose above

and then build your series on top.  Remember to describe what you
did to prepare the base in your cover letter.

Don't directly base your changes to 'next', which would mean your
topic will never graduate to 'master', as it is taken hostage by all
the topics in 'next' (and the merge commits that merge these topics
into 'next', which will never be merged to 'master').

Thanks.