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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 30, 2021 at 06:33:18PM -0400, Taylor Blau wrote:

> 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?

Adding my two cents: yes, I think it most definitely should be a
separate issue. As you demonstrated, differing config between alternates
and repos that point to them is not specific to the midx code. I agree
with brian's "well, don't do that". But _if_ we want to try to behave
better in such a case, whatever we changes we make would then naturally
apply to the midx code as well.

The two midx-specific things we have to care about are:

  - is it OK for the midx command to refuse to operate when we are not
    in a repository at all? I think yes; we can't even know which hash
    is being used, along with who knows what other lurking
    complications.

  - is it OK to restrict the midx command's --object-dir to only operate
    on a directory which is an alternate of the current repo? I think
    yes again. If it _isn't_ related, we have all the lurking problems
    from the first point, but even worse (because we use config, refs,
    and other information from our current repo with the _totally
    unrelated_ object dir).

So I'm all in favor of locking those down now before things get any more
complicated. If we later want to make the object store more aware of of
differences between alternates and the main store (like say, the object
hash in use), then we could consider loosening using the same mechanism.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux