Hi all,
While investigating the last issue I reported (and fixed) I was trying
to come up with a good test case for repos with large objects. In the
process I found an issue on Windows with objects at least 4g large:
git init test
cd test
echo "*.exe binary" > .gitattributes
truncate -s 4g nullby
.
Signed-off-by: Patrick Hogg
Thanks-to: Junio C Hamano
---
builtin/pack-objects.c | 24 ++--
pack-objects.c | 5 +
pack-objects.h | 21 -
3 files changed, 19 insertions(+), 31 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin
f which is called before the first invocation of
ll_find_deltas. As such the read mutex is not guaranteed to be
initialized.
Resolve this by moving the read mutex to packing_data and initializing
it in prepare_packing_data which is initialized in cmd_pack_objects.
Signed-off-by: Patrick Hogg
Review
On Thu, Jan 24, 2019 at 2:49 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > On Thu, Jan 24, 2019 at 8:06 AM Patrick Hogg wrote:
> >> diff --git a/pack-objects.h b/pack-objects.h
> >> index 0a038e3bc..dc869f26c 100644
> >> --- a/pack-objects.
Upgrade the packing_data lock to a recursive mutex to make it suitable
for current read_lock usages. Additionally remove the superfluous
#ifndef NO_PTHREADS guard around mutex initialization in
prepare_packing_data as the mutex functions themselves are already
protected.
Signed-off-by: Patrick
f which is called before the first invocation of
ll_find_deltas. As such the read mutex is not guaranteed to be
initialized.
Resolve this by moving the read mutex to packing_data and initializing
it in prepare_packing_data which is initialized in cmd_pack_objects.
Signed-off-by: Patrick Hogg
--
On Tue, Jan 22, 2019 at 5:43 PM Junio C Hamano wrote:
>
> Patrick Hogg writes:
>
> > As I mentioned in the prior thread I think that it will be simpler
> > to simply use the existing lock in packing_data instead of moving
> > read_mutex. I can go back to simp
On Tue, Jan 22, 2019 at 5:26 AM Duy Nguyen wrote:
>
> On Tue, Jan 22, 2019 at 2:28 PM Jeff King wrote:
> >
> > On Mon, Jan 21, 2019 at 05:02:33PM +0700, Duy Nguyen wrote:
> >
> > > > As I mentioned in the prior thread I think that it will be simpler
> > > > to simply use the existing lock in pack
recursive mutex to
make it a suitable replacement for read_mutex.
Signed-off-by: Patrick Hogg
---
As I mentioned in the prior thread I think that it will be simpler
to simply use the existing lock in packing_data instead of moving
read_mutex. I can go back to simply moving read_mutex to the
pa
On Fri, Jan 18, 2019 at 8:10 AM Duy Nguyen wrote:
>
> On Fri, Jan 18, 2019 at 8:04 PM Patrick Hogg wrote:
> >
> > On Fri, Jan 18, 2019 at 4:21 AM Duy Nguyen wrote:
> >>
> >> On Fri, Jan 18, 2019 at 9:28 AM Patrick Hogg wrote:
> >> >
> >>
On Fri, Jan 18, 2019 at 4:21 AM Duy Nguyen wrote:
>
> On Fri, Jan 18, 2019 at 9:28 AM Patrick Hogg wrote:
> >
> > ac77d0c37 ("pack-objects: shrink size field in struct object_entry",
> > 2018-04-14) added an extra usage of read_lock/read_unlock in the newly
&
f which is called before the first invocation of
ll_find_deltas. As such the read mutex is not guaranteed to be
initialized.
Resolve this by splitting off the read mutex initialization from
init_threaded_search. Instead initialize (and clean up) the read
mutex in cmd_pack_objects.
Signed-off-by: Pa
12 matches
Mail list logo
