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

3 messages, 3 authors, 2021-08-30 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2021-08-30 00:34:24

Taylor Blau [off-list ref] writes:
now or later would affect this series. Even if we just disallow
--object-dir pointing at a non-alternate repository, we would still have
the issue of having alternate chains which don't all have the same
object format.
Exactly.  That is why I feel that it probably needs to be dealt with
before doing anything else.  The alternate mechanism pulling in an
object store that uses incompatible hash algo would break not just
the multi-pack-index but probably the basic object access layer as
well, which would be more grave problem, no?
My inclination would be to
send a new version that simply requires the MIDX builtin to be run from
within a repository (as well as the cleanups from Johannes).
Sounds like a good first step.

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

From: Taylor Blau <hidden>
Date: 2021-08-30 00:43:33

On Sun, Aug 29, 2021 at 05:34:18PM -0700, Junio C Hamano wrote:
Taylor Blau [off-list ref] writes:
quoted
now or later would affect this series. Even if we just disallow
--object-dir pointing at a non-alternate repository, we would still have
the issue of having alternate chains which don't all have the same
object format.
Exactly.  That is why I feel that it probably needs to be dealt with
before doing anything else.  The alternate mechanism pulling in an
object store that uses incompatible hash algo would break not just
the multi-pack-index but probably the basic object access layer as
well, which would be more grave problem, no?
Yeah; it does. Maybe I'm holding it wrong (and brian, cc'd, can help
me), but this is an easy way to see the problem:

  git init repo
  git init alternate

  git -C repo commit --allow-empty -m foo
  ( cd repo/.git/objects && pwd ) >alternate/.git/objects/info/alternates
  git -C alternate rev-list --objects --alternate-refs

which will produce:

    $ git rev-list --objects --alternate-refs
    warning: invalid line while parsing alternate refs: <sha256 id>

But I don't know if I quite understand your "probably needs to be dealt
with before doing anything else". I think we can proceed with this
series and deal with the alternate object-format thing separately, no?

Thanks,
Taylor

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

From: brian m. carlson <hidden>
Date: 2021-08-30 22:11:18

On 2021-08-30 at 00:43:30, Taylor Blau wrote:
On Sun, Aug 29, 2021 at 05:34:18PM -0700, Junio C Hamano wrote:
quoted
Taylor Blau [off-list ref] writes:
quoted
now or later would affect this series. Even if we just disallow
--object-dir pointing at a non-alternate repository, we would still have
the issue of having alternate chains which don't all have the same
object format.
Exactly.  That is why I feel that it probably needs to be dealt with
before doing anything else.  The alternate mechanism pulling in an
object store that uses incompatible hash algo would break not just
the multi-pack-index but probably the basic object access layer as
well, which would be more grave problem, no?
Yeah; it does. Maybe I'm holding it wrong (and brian, cc'd, can help
me), but this is an easy way to see the problem:

  git init repo
  git init alternate

  git -C repo commit --allow-empty -m foo
  ( cd repo/.git/objects && pwd ) >alternate/.git/objects/info/alternates
  git -C alternate rev-list --objects --alternate-refs

which will produce:

    $ git rev-list --objects --alternate-refs
    warning: invalid line while parsing alternate refs: <sha256 id>

But I don't know if I quite understand your "probably needs to be dealt
with before doing anything else". I think we can proceed with this
series and deal with the alternate object-format thing separately, no?
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.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help