Johannes Schindelin writes:
> On 2015-06-26 19:37, Junio C Hamano wrote:
>> Jeff King writes:
>>
>>> On Fri, Jun 26, 2015 at 10:06:20AM +0200, Johannes Schindelin wrote:
>>>
I understood what you were saying, but it still appears too fragile to
me to mix functions that assume NUL-term
Hi Junio,
On 2015-06-26 19:37, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Fri, Jun 26, 2015 at 10:06:20AM +0200, Johannes Schindelin wrote:
>>
>>> I understood what you were saying, but it still appears too fragile to
>>> me to mix functions that assume NUL-terminated strings with an ad-h
Jeff King writes:
> On Fri, Jun 26, 2015 at 10:06:20AM +0200, Johannes Schindelin wrote:
>
>> I understood what you were saying, but it still appears too fragile to
>> me to mix functions that assume NUL-terminated strings with an ad-hoc
>> counted string check.
>
> Yeah, I agree. It is not that
On Fri, Jun 26, 2015 at 10:06:20AM +0200, Johannes Schindelin wrote:
> I understood what you were saying, but it still appears too fragile to
> me to mix functions that assume NUL-terminated strings with an ad-hoc
> counted string check.
Yeah, I agree. It is not that you cannot make it safe, but
Hi Junio,
On 2015-06-26 00:29, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Johannes Schindelin writes:
>> ...
>>> If the buffer does *not* contain an empty line, the fsck code runs the
>>> danger of looking beyond the allocated memory because it uses
>>> functions that assume NUL-termin
Junio C Hamano writes:
> Johannes Schindelin writes:
> ...
>> If the buffer does *not* contain an empty line, the fsck code runs the
>> danger of looking beyond the allocated memory because it uses
>> functions that assume NUL-terminated strings, while the buffer passed
>> to the fsck code is a
Johannes Schindelin writes:
> Hi Junio & Wolfgang,
>
> On 2015-06-25 22:24, Junio C Hamano wrote:
>> Wolfgang Denk writes:
>>
>>> In message you wrote:
> Question is: how can we fix that?
It could be that 4d0d8975 is buggy and barking at a non breakage.
>
> Well, I would li
Hi Junio & Wolfgang,
On 2015-06-25 22:24, Junio C Hamano wrote:
> Wolfgang Denk writes:
>
>> In message you wrote:
>>>
>>> > Question is: how can we fix that?
>>>
>>> It could be that 4d0d8975 is buggy and barking at a non breakage.
Well, I would like to believe that this commit made our code
Wolfgang Denk writes:
> Hm... it seems I cannot even easily delte these tags:
>
> -> git tag -d LABEL_2006_03_12_0025
> Deleted tag 'LABEL_2006_03_12_0025' (was eb394f5)
> -> git fsck --full
> Checking object directories: 100% (256/256), done.
> Checking object directories: 100% (256/256), done.
Wolfgang Denk writes:
> Dear Junio,
>
> thanks for the fast replies.
>
> In message you wrote:
>>
>> > Question is: how can we fix that?
>>
>> It could be that 4d0d8975 is buggy and barking at a non breakage.
>>
>> If there is no message in the tag, i.e.
>>
>> -- 8< --
>> object 84ef
Dear Junio,
thanks for the fast replies.
In message you wrote:
>
> > Question is: how can we fix that?
>
> It could be that 4d0d8975 is buggy and barking at a non breakage.
>
> If there is no message in the tag, i.e.
>
> -- 8< --
> object 84ef51a632063e8cb57b2e9a4252497512831ffe
>
Wolfgang Denk writes:
> it turns out that recent versions of git (i. e. git version 2.2.0 or
> later, resp. anything which includes commit 4d0d8975 "Make sure
> fsck_commit_buffer() does not run out of the buffer") throws errors on
> our git repository git://git.denx.de/u-boot:
>
> -> git fsck -
Wolfgang Denk writes:
> Apparently for some reason the tags LABEL_2006_03_12_0025,
> LABEL_2006_04_18_1106, and LABEL_2006_05_19_1133 are missing newlines,
> which was undetected so far, but now is raised as an error.
>
> Question is: how can we fix that?
>
> Is there a tool to "auto-repair" suc
Hi all,
it turns out that recent versions of git (i. e. git version 2.2.0 or
later, resp. anything which includes commit 4d0d8975 "Make sure
fsck_commit_buffer() does not run out of the buffer") throws errors on
our git repository git://git.denx.de/u-boot:
-> git fsck --full
Checking object dire
14 matches
Mail list logo
