On 12/09, Brandon Williams wrote: > On 12/09, Duy Nguyen wrote: > > On Fri, Dec 9, 2016 at 1:19 AM, Brandon Williams <bmw...@google.com> wrote: > > > On 12/08, Duy Nguyen wrote: > > >> On Thu, Dec 8, 2016 at 7:03 AM, Brandon Williams <bmw...@google.com> > > >> wrote: > > >> > On 12/07, Duy Nguyen wrote: > > >> >> On Wed, Dec 7, 2016 at 4:51 AM, Brandon Williams <bmw...@google.com> > > >> >> wrote: > > >> >> > Convert 'create_simplify()' to use the pathspec struct interface > > >> >> > from > > >> >> > using the '_raw' entry in the pathspec. > > >> >> > > >> >> It would be even better to kill this create_simplify() and let > > >> >> simplify_away() handle struct pathspec directly. > > >> >> > > >> >> There is a bug in this code, that might have been found if we > > >> >> simpify_away() handled pathspec directly: the memcmp() in > > >> >> simplify_away() will not play well with :(icase) magic. My bad. If > > >> >> :(icase) is used, the easiest/safe way is simplify nothing. Later on > > >> >> maybe we can teach simplify_away() to do strncasecmp instead. We could > > >> >> ignore exclude patterns there too (although not excluding is not a > > >> >> bug). > > >> > > > >> > So are you implying that the simplify struct needs to be killed? That > > >> > way the pathspec struct itself is being passed around instead? > > >> > > >> Yes. simplify struct was a thing when pathspec was an array of char *. > > >> At this point I think it can retire (when we have time to retire it) > > > > > > Alright, then for now I can leave this change as is and have a follow up > > > series that kills the simplify struct. > > > > Do let me know if you decide to drop it, so I can put it back in my backlog. > > K will do >
This actually turned out to be more straight forward than I thought. I'll reroll this series again (with a few other changes) and include killing the simplify struct. -- Brandon Williams
