Re: [PATCH v2 12/16] pathspec: create parse_long_magic function
- From
- Brandon Williams <bmwill@google.com>
- Date
- Dec 10, 2016, 00:29 UTC
- Message-ID
- <20161210002923.GG88637@google.com>
- In-Reply-To
- <CAGZ79ka0P0rKF8QH3V0jC-O19eT0oaE+fJLGifbfmm3jC_SijA@mail.gmail.com>
On 12/09, Stefan Beller wrote:
Show 39 quoted lines
> On Fri, Dec 9, 2016 at 3:44 PM, Junio C Hamano <gitster@pobox.com> wrote: > > Brandon Williams <bmwill@google.com> writes: > > > >> Factor out the logic responsible for parsing long magic into its own > >> function. As well as hoist the prefix check logic outside of the inner > >> loop as there isn't anything that needs to be done after matching > >> "prefix:". > >> > >> Signed-off-by: Brandon Williams <bmwill@google.com> > > > > These refactoring changes look like they are all going in the good > > direction. Stefan's :(attr:<attribute spec>)path" changes however > > have severe conflicts (e.g. the topic already does something similar > > to this step and calls the factored-out function eat_long_magic()). > > > > My gut feeling is that we probably should ask Stefan's series to be > > rebased on top of this series that cleans up pathspec implementation, > > once it stabilizes. > > Very much so. > > Jonathan Nieder mentioned off list that he prefers to see that > series rerolled without mutexes if possible. That is possible by > creating the questions "struct attr_check" before preloading the > index and then using the read only questions in the threaded code, > to obtain answers fast; also no need for a mutex. > > I did not look into that yet, though. So I think you could discard that > series (again) until I find time to either redo the series or > resend it with a proper explanation on why the approach above > is not feasible. > > > We could probably go the other way around, but > > logically it makes more sense to build "pathspec can also match > > using attributes information" on top of a refactored codebase. > > > > Thoughts? > > Please let the refactoring in in favor of the attr series.
Sounds good. I only looked at your series briefly, but I'm hoping that these refactoring changes I'm proposing make it relatively easy for you to build on top of in the future.
-- Brandon Williams