On Wed, Aug 16, 2017 at 10:22:39PM +0200, Martin Koegler wrote:
> On Mon, Aug 14, 2017 at 10:08:05AM -0700, Junio C Hamano wrote:
> >It may help reducing the maintenance if we introduced obj_size_t
> >that is defined to be size_t for now, so that we can later swap
> >it to ofs_t or some
On Mon, Aug 14, 2017 at 10:08:05AM -0700, Junio C Hamano wrote:
>It may help reducing the maintenance if we introduced obj_size_t
>that is defined to be size_t for now, so that we can later swap
>it to ofs_t or some larger type when we know we do need to
>support objects whose size
On 14/08/17 21:32, Torsten Bögershausen wrote:
> In general, yes.
> I had a patch that allowed a 32 bit linux to commit a file >4GB.
> There is however a restriction: The file must not yet be known to the
> index. Otherwise the "diff" machinery kicks in, and tries to
> compare the "old" and the "
On Mon, Aug 14, 2017 at 08:31:50PM +0100, Ramsay Jones wrote:
>
>
> On 14/08/17 18:08, Junio C Hamano wrote:
> > Junio C Hamano writes:
> >
> >> One interesting question is which of these two types we should use
> >> for the size of objects Git uses.
> >>
> >> Most of the "interesting" operat
Ramsay Jones writes:
> In a previous comment, I said that (on 32-bit Linux) it was likely
> that an object of > 4GB could not be handled correctly anyway. (more
> likely > 2GB). This was based on the code from (quite some) years ago.
> In particular, before you added the "streaming API". So, mayb
On 14/08/17 18:08, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> One interesting question is which of these two types we should use
>> for the size of objects Git uses.
>>
>> Most of the "interesting" operations done by Git require that the
>> thing is in core as a whole before we can d
Junio C Hamano writes:
> One interesting question is which of these two types we should use
> for the size of objects Git uses.
>
> Most of the "interesting" operations done by Git require that the
> thing is in core as a whole before we can do anything (e.g. compare
> two such things to produc
Ramsay Jones writes:
> It should be, see commit b97e911643 ("Support for large files
> on 32bit systems.", 17-02-2007), where you can see that the
> _FILE_OFFSET_BITS macro is set to 64. This asks et.al.,
> to use the "Large File System" API and a 64-bit off_t.
Correct. Roughly speaking, we sh
On 13/08/17 19:30, Martin Koegler wrote:
> On Sat, Aug 12, 2017 at 02:47:25PM +0100, Ramsay Jones wrote:
>> On 32-bit Linux, off_t is 64-bit and size_t is 32-bit.
>
> --- t.c ---
> #include
> #include
>
> int main()
> {
> printf("%d %d\n", sizeof(size_t), sizeof(off_t));
> }
>
>
On Sat, Aug 12, 2017 at 02:47:25PM +0100, Ramsay Jones wrote:
> On 32-bit Linux, off_t is 64-bit and size_t is 32-bit.
--- t.c ---
#include
#include
int main()
{
printf("%d %d\n", sizeof(size_t), sizeof(off_t));
}
$ gcc -m32 -o t t.c
$ ./t.c
4 4
So is that really true?
Regards,
M
On Sat, Aug 12, 2017 at 11:59:15AM +0200, Torsten Bögershausen wrote:
> Thanks for working on this - unfortunatly the patch does not apply on
> git.git/master.
>
> Which baseline did you use ?
next - 98096fd7a85b93626db8757f944f2d8ffdf7e96a
It accumulated to 19 patches.
Regards,
Martin
On 12/08/17 09:47, Martin Koegler wrote:
> From: Martin Koegler
>
> Signed-off-by: Martin Koegler
> ---
> builtin/pack-objects.c | 48
> 1 file changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/builtin/pack-objects.c b/builtin/pack-o
Thanks for working on this - unfortunatly the patch does not apply on
git.git/master.
Which baseline did you use ?
From: Martin Koegler
Signed-off-by: Martin Koegler
---
builtin/pack-objects.c | 48
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index aa70f80..f8db283 100644
--- a/builtin/pack-o
14 matches
Mail list logo
