From: Jeff King <peff@peff.net>
To: Matheus Tavares Bernardino <matheus.bernardino@usp.br>
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 06:04:01 -0500 [thread overview]
Message-ID: <20200201110401.GA1864948@coredump.intra.peff.net> (raw)
In-Reply-To: <CAHd-oW4WBc0AmcZwmOBNNMVQW=JZ-pVhXf8ebL9exgPp13VvOQ@mail.gmail.com>
On Sat, Feb 01, 2020 at 01:44:04AM -0300, Matheus Tavares Bernardino wrote:
> > 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?
Yes, by the reasoning in my message, it wouldn't be a big problem. But I
literally hadn't thought about it until writing that, so I may either be
missing something, or there may be plans from other folks working on the
hash transition that contradict that.
Even if we don't care too much about it for now, though, it still seems
like a step in the right direction.
-Peff
prev parent reply other threads:[~2020-02-01 11:04 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
2020-02-01 11:04 ` Jeff King [this message]
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=20200201110401.GA1864948@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=matheus.bernardino@usp.br \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).