On Thu, Sep 12, 2013 at 11:44:30AM +0200, Matthieu Moy wrote:

> That is clean, but a bit long and it is essentially duplicated between
> status and commit. I went another way: put all the similar code in a
> common function status_init_config:
> static void status_init_config(struct wt_status *s, config_fn_t fn)
> {
>       wt_status_prepare(s);
>       gitmodules_config();
>       git_config(git_status_config, s);
>       determine_whence(s);
>       s->hints = advice_status_hints; /* must come after git_config() */
> }

s/git_status_config/fn/, I assume.

> We could split the git_config call, but that would not bring much
> benefit IMHO. In any case, it can be done very simply on top of my patch
> if needed later, as there is now only one call site for git_config.

Yeah, I think that is fine. The other cleanup may or may not be worth
it, but should not be a blocker to your patch. With what you suggest
above, you are certainly not making anything worse with respect to the
code organization.


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

Reply via email to