Re: [PATCH 22/27] sha1_file: allow sha1_file_name to handle arbitrary repositories
- From
Stefan Beller <sbeller@google.com>
- Date
- Feb 23, 2018, 22:50 UTC
- Message-ID
- <CAGZ79kaSTz+CjpZ8cijRcK_npWnh1TK9btzgWAXPHUDYKx--cQ@mail.gmail.com>
- In-Reply-To
- <20180221164406.c98170765e454b51de80c680@google.com>
On Wed, Feb 21, 2018 at 4:44 PM, Jonathan Tan <jonathantanmy@google.com> wrote:
Show 24 quoted lines
> On Tue, 20 Feb 2018 17:54:25 -0800
> Stefan Beller <sbeller@google.com> wrote:
>
>> Signed-off-by: Stefan Beller <sbeller@google.com>
>> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
>
> Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
>
>> -void sha1_file_name_the_repository(struct strbuf *buf, const unsigned char *sha1)
>> +void sha1_file_name(struct repository *r, struct strbuf *buf, const unsigned char *sha1)
>> {
>> - strbuf_addstr(buf, get_object_directory());
>> + strbuf_addstr(buf, r->objects.objectdir);
>> strbuf_addch(buf, '/');
>> fill_sha1_path(buf, sha1);
>> }
>
> In the future, we should probably have:
> - a function to get the object store out of a repo (so that it can
> lazily initialize the object store struct if necessary)
> - when the object store is obtained, its objectdir field is guaranteed
> to be populated
> - sha1_file_name should take the object store struct, not the repo
> structWe had that in v2, but I reverted it as the consensus seemed that we prefer the_repository to be passed around.
> > but this is outside the scope of this patch.