Re: [PATCH 5/6] log: pass rev_info to git_log_config()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 04, 2012 at 09:16:14PM -0700, Junio C Hamano wrote:

> Junio C Hamano <gitster@xxxxxxxxx> writes:
> 
> > So we would need to do something like:
> >
> >     - call git_log_config() first to let diff_context_default
> >       updated from the configuration as before.  find the values of
> >       grep.* defaults at the same time, but stash it away in a
> >       separate "struct grep_opt" (yuck);
> >
> >     - call init_revisions() and let it initialize revs->grep_filter
> >       and revs->diffopt as before;
> >
> >     - copy the grep.* defaults we learned during git_log_config() to
> >       revs->grep_filter.
> >
> > which is a bit yucky, but survivable.
> 
> After thinking about it a bit more, I came to a conclusion that the
> configuration handling lifted from builtin/grep.c needs a much
> larger overhaul.
> [...]
> The right way to arrange your configuration callback is probably to
> model it after how diff configuration variables are handled.  You
> call git_config() once, and remember the values you read in set of
> static variables. Later, whenever you need to instantiate a grep_opt,
> you initialize it from these static variables.

Agreed. Maybe the simplest thing would be to have grep_config fill in a
"static struct grep_opt grep_defaults", and then memcpy that into place
during init_revisions?

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]