From: Matheus Tavares Bernardino <matheus.bernardino@usp.br>
To: Jeff King <peff@peff.net>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH 0/7] fix inconsistent uses of the_repo in parse_object()'s call chain
Date: Sat, 1 Feb 2020 01:44:04 -0300 [thread overview]
Message-ID: <CAHd-oW4WBc0AmcZwmOBNNMVQW=JZ-pVhXf8ebL9exgPp13VvOQ@mail.gmail.com> (raw)
In-Reply-To: <20200131090329.GB2857810@coredump.intra.peff.net>
Hi, Peff
Thanks for the great feedback.
On Fri, Jan 31, 2020 at 6:03 AM Jeff King <peff@peff.net> wrote:
>
[...]
> The hash transition document says:
>
> To convert recorded submodule pointers, you need to have the converted
> submodule repository in place. The translation table of the submodule
> can be used to look up the new hash.
>
> which I take to mean that the local copy of the submodule needs to match
> the superproject hash (this says nothing about what the upstream owner
> of the submodule wants to do; we'd be translating on the fly to the new
> hash in the local repo). So using the_hash_algo would work either way.
>
> I don't think we're particularly interested in supporting multiple
> unrelated repositories within the same process. While that would be
> convenient for some cases (e.g., you have a million repositories and
> want to look at all of their trees without creating a million
> processes), I don't think it's a goal anyone is really working towards
> with this "struct repository" layer.
Thanks for these explanations. One thing that left me thinking,
though, is about changing the_hash_algo to r->hash_algo (not only in
oid_to_hex()). I previously thought this would eventually be required
for the hash transition. But if I understood your comment correctly,
it might not be necessary since the submodule should always match the
superproject hash. And, as you mentioned, supporting multiple
unrelated repos [in a single process] is not one of the main goals, as
well. So wouldn't keep using the_hash_algo be OK?
next prev parent reply other threads:[~2020-02-01 4:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-30 20:32 [PATCH 0/7] fix inconsistent uses of the_repo in parse_object()'s call chain Matheus Tavares
2020-01-30 20:32 ` [PATCH 1/7] diff: make diff_populate_filespec() honor its repo argument Matheus Tavares
2020-01-30 20:32 ` [PATCH 2/7] cache-tree: use given repo's hash_algo at verify_one() Matheus Tavares
2020-01-30 20:32 ` [PATCH 3/7] pack-check: use given repo's hash_algo at verify_packfile() Matheus Tavares
2020-01-30 20:32 ` [PATCH 4/7] streaming: allow open_istream() to handle any repo Matheus Tavares
2020-01-31 18:55 ` Junio C Hamano
2020-01-30 20:32 ` [PATCH 5/7] sha1-file: pass git_hash_algo to write_object_file_prepare() Matheus Tavares
2020-02-01 10:03 ` Torsten Bögershausen
2020-02-01 11:08 ` Jeff King
2020-01-30 20:32 ` [PATCH 6/7] sha1-file: pass git_hash_algo to hash_object_file() Matheus Tavares
2020-01-30 20:32 ` [PATCH 7/7] sha1-file: allow check_object_signature() to handle any repo Matheus Tavares
2020-01-30 21:26 ` [PATCH 0/7] fix inconsistent uses of the_repo in parse_object()'s call chain Junio C Hamano
2020-01-30 23:46 ` brian m. carlson
2020-01-31 9:03 ` Jeff King
2020-02-01 4:44 ` Matheus Tavares Bernardino [this message]
2020-02-01 11:04 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHd-oW4WBc0AmcZwmOBNNMVQW=JZ-pVhXf8ebL9exgPp13VvOQ@mail.gmail.com' \
--to=matheus.bernardino@usp.br \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.