Jeff King writes:
> The string handling in link_alt_odb_entry() is mostly an
> artifact of the original version, which took the path as a
> ptr/len combo, and did not have a NUL-terminated string
> until we created one in the alternate_object_database
> struct. But since 5bdf0a8 (sha1_file: norm
On Tue, Oct 4, 2016 at 6:53 AM, Jeff King wrote:
> On Mon, Oct 03, 2016 at 11:05:42PM -0700, Jacob Keller wrote:
>
>> This definitely makes reading the following function much easier,
>> though the diff is a bit funky. I think the end result is much
>> clearer.
>
> Yeah, it's really hard to see th
On Mon, Oct 03, 2016 at 11:05:42PM -0700, Jacob Keller wrote:
> This definitely makes reading the following function much easier,
> though the diff is a bit funky. I think the end result is much
> clearer.
Yeah, it's really hard to see that all of the "ent" setup is kept,
because it moves _and_ c
On Mon, Oct 3, 2016 at 1:34 PM, Jeff King wrote:
> The string handling in link_alt_odb_entry() is mostly an
> artifact of the original version, which took the path as a
> ptr/len combo, and did not have a NUL-terminated string
> until we created one in the alternate_object_database
> struct. But
The string handling in link_alt_odb_entry() is mostly an
artifact of the original version, which took the path as a
ptr/len combo, and did not have a NUL-terminated string
until we created one in the alternate_object_database
struct. But since 5bdf0a8 (sha1_file: normalize alt_odb
path before comp
5 matches
Mail list logo
