Re: recommendation for patch maintenance

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 21, 2012, 22:17 UTC
Message-ID: <CAPc5daXp4cYG_Qy3_n__nSw4F_u73evzm7P1in_74Rs42mNSrg@mail.gmail.com>
In-Reply-To: <50D4D511.4010003@gmail.com>

On Fri, Dec 21, 2012 at 1:30 PM, Manlio Perillo <manlio.perillo@gmail.com> wrote:

Show 10 quoted lines

>
> By the way, I would also like to be able to set the default value for
> the --output option in config file; something like:
>
>   [format]
>   output = +mp/$(git symbolic-ref --short HEAD)
>
> where the string will be processed by the shell:
>
>    sh -c 'printf "+mp/$(git symbolic-ref --short HEAD)'"

My knee-jerk reaction is that, while it might make sense to give an option to allow users to use a dedicated directory per branch, I am not interested in that form; especially the part that lets the users too long a rope to hang themselves with by allowing an arbitrary shell expansions goes against my taste.

But you *can* prove me wrong; read on.

> I should be able to hack the patch in the weekend, but I'm not sure it
> will be accepted.

You got it backwards, just like many other new people who come and go on this list. If something is very useful, you'd work on it even if the result may not appear immediately in the upstream, and you'd keep maintaining a local fork so that you can keep benefiting from it, once you have written such a useful feature (whatever it is). If even the original "itch-holder" does not think that the benefit from his change outweighs the cost of such an effort, why should *I* carry it in my tree?

The goal of a contributor who comes up with an idea, gets "It doesn't sound like a good idea" during the review but disagrees and believes in his idea ought to be to prove the reviewer(s) wrong by polishing the idea and the implementation so much that the upstream comes begging for your change ;-)

The core part of the change to add --reroll $n option should be straight-forward and will involve a few functions in builtin/log.c, but the existing code is so badly structured that it probably needs a couple of "preparatory steps" patch to clean up the API between internal functions on that codepath, before the real change can be made, I think.