On Fri, Dec 21, 2012 at 1:30 PM, Manlio Perillo
<manlio.peri...@gmail.com> wrote:
>
> 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.
--
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