Re: [PATCH v4 05/25] midx: clear auxiliary .rev after replacing the MIDX

On Tue, Aug 31, 2021 at 09:29:46AM -0700, Junio C Hamano wrote:

Taylor Blau [off-list ref] writes:

quoted

On Mon, Aug 30, 2021 at 03:28:47PM -0700, Junio C Hamano wrote:

quoted

"brian m. carlson" [off-list ref] writes:

quoted

Yeah, this is a possible problem.  You can also see it when using git
index-pack outside of a repository with an incorrect --object-format
option.

I'm not sure how folks want to deal with that; I'm just fine saying,
"Well, don't do that," but other folks may have different opinions.

OK, so if we go back to the original breakage of the test script
that triggered this discussion, the right solution would be to make
sure both test repositories/object stores are prepared with the
algorithm specified with GIT_TEST_DEFAULT_HASH?

Just to make sure do you still see this as a separate issue from running
the midx builtin outside of a repository?

They are separate issues, but the .midx issue has a small overlap
with the much bigger "do not mix repositories and object stores with
different hashes" issue.

OK, good. Everything you wrote below (which I snipped off in my reply)
makes sense to me, and seems like a worthwhile direction to pursue
outside of this series, especially as more users start using sha256
repositories.

I think it makes sense for the midx command to require being in a
repository to run (to establish what "the current repository" is)
and insist on the other object store given with --object-dir to be
"compatible" with the current repository (i.e. the same hash
algorithm, there may be others).  I am a bit fuzzy why we want it
to be already our alternate.

I don't think there's any strict requirement to the other repository
being our alternate, other than touching arbitrary repositories is a
surprising behavior that appears (to me, at least) to be inconsistent
with the rest of Git.

After (the rerolled version of) this series, we'll be in a state where:

  - `git multi-pack-index` will not run when outside of a Git
    repository.
  - The `--object-dir` argument will only recognize object directories
    belonging to an alternate of the current repository.
  - Using `--object-dir` to point to a repository which uses a
    different hash than the repository in the current working directory
    will continue to not work (as was the case before this series).

I think(?) that there is consensus for that approach, so patches
incoming...

Thanks.

(Thank you, by the way, for clarifying this all in so much detail. I
would much rather just have code to talk about, but it feels
particularly important to be on the same page beforehand in this
instance, since there is *so much* code, and this discussion is centered
around so little of it).

Thanks,
Taylor