On Tue, Aug 31, 2021 at 09:29:46AM -0700, Junio C Hamano wrote:
> Taylor Blau <me@xxxxxxxxxxxx> writes:
>
> > On Mon, Aug 30, 2021 at 03:28:47PM -0700, Junio C Hamano wrote:
> >> "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes:
> >>
> >> > 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
