Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

2016-11-08 Thread Bryan Turner
> >> Is there anything I can do to help? I'm happy to test out changes. > > The patch at the end of his mail obviously passes the newly-added tests > for me, but please confirm that it fixes your test suite. > > I gather your suite is about noticing behavior changes between different > versions.

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

2016-11-07 Thread Jeff King
On Mon, Nov 07, 2016 at 05:12:43PM -0800, Bryan Turner wrote: > > The obvious solution is one of: > > > > 1. Stop calling normalize() at all when we do not have a relative base > > and the path is not absolute. This restores the original quirky > > behavior (plus makes the

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

2016-11-07 Thread Bryan Turner
On Mon, Nov 7, 2016 at 4:30 PM, Jeff King wrote: > On Mon, Nov 07, 2016 at 03:42:35PM -0800, Bryan Turner wrote: > >> > @@ -335,7 +340,9 @@ static void link_alt_odb_entries(const char *alt, int >> > len, int sep, >> > } >> > >> > strbuf_add_absolute_path(,

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

2016-11-07 Thread Jeff King
On Mon, Nov 07, 2016 at 03:42:35PM -0800, Bryan Turner wrote: > > @@ -335,7 +340,9 @@ static void link_alt_odb_entries(const char *alt, int > > len, int sep, > > } > > > > strbuf_add_absolute_path(, get_object_directory()); > > - normalize_path_copy(objdirbuf.buf,

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

2016-11-07 Thread Bryan Turner
On Mon, Oct 3, 2016 at 1:34 PM, Jeff King wrote: > When we add a new alternate to the list, we try to normalize > out any redundant "..", etc. However, we do not look at the > return value of normalize_path_copy(), and will happily > continue with a path that could not be

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

2016-10-05 Thread Jeff King
On Wed, Oct 05, 2016 at 08:47:29PM +0200, René Scharfe wrote: > > Instead, let's provide a strbuf helper that does an in-place > > normalize, but restores the original contents on error. This > > uses a second buffer under the hood, which is slightly less > > efficient, but this is not a

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

2016-10-05 Thread René Scharfe
Am 03.10.2016 um 22:34 schrieb Jeff King: When we add a new alternate to the list, we try to normalize out any redundant "..", etc. However, we do not look at the return value of normalize_path_copy(), and will happily continue with a path that could not be normalized. Worse, the normalizing

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

2016-10-04 Thread Junio C Hamano
Jeff King writes: > +int strbuf_normalize_path(struct strbuf *src) > +{ > + struct strbuf dst = STRBUF_INIT; > + > + strbuf_grow(, src->len); > + if (normalize_path_copy(dst.buf, src->buf) < 0) { > + strbuf_release(); > + return -1; > + } >

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

2016-10-04 Thread Jacob Keller
On Mon, Oct 3, 2016 at 1:34 PM, Jeff King wrote: > When we add a new alternate to the list, we try to normalize > out any redundant "..", etc. However, we do not look at the > return value of normalize_path_copy(), and will happily > continue with a path that could not be

[PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

2016-10-03 Thread Jeff King
When we add a new alternate to the list, we try to normalize out any redundant "..", etc. However, we do not look at the return value of normalize_path_copy(), and will happily continue with a path that could not be normalized. Worse, the normalizing process is done in-place, so we are left with