On 5/9/2019 5:56 AM, Duy Nguyen wrote: > On Wed, May 8, 2019 at 10:52 PM Derrick Stolee <sto...@gmail.com> wrote: >> >> The biggest issue with my suggestion is that it requires changing the >> consumers of the options, as they would no longer live directly on the >> rev_info struct. That would be a big change, even if it could be done >> with string replacement. > > I agree rev_info has grown "wild". It's quite ancient code. As you > noted, it's a big change. And since my series is already long (76 > patches), I would rather focus on just one thing, rewriting the > parsing code with minimum changes to anything else, preferably retain > the exact same old behavior. > > After that work is done (and no regression found), we could focus on > reorganizing rev_info, which could be quite "interesting". Some fields > may be overloaded with different purposes, which I just can't spend > time investigating now. There's also the problem with freeing > resources after rev-list is done, which I think we have ignored so > far.
Thanks for humoring me. I agree with your reasoning. This series looks good to me. Thanks, -Stolee
