Jay Soffian <jaysoffian@xxxxxxxxx> writes:
> On Fri, Mar 6, 2009 at 5:46 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
>> When you are on branch "frotz", your config have both merge.options and
>> branch.frotz.mergeoptions, and you give some other options from the
>> command line, how should they interact? I'd expect the branch.*.options
>> to take effect, ignoring merge.options entirely.
>
> Really? I didn't think that would be consistent with the fact that the
> the command line options override branch.*.options, but don't replace
> them.
I think cumulative option in configuration is bad in practice, but I'll
explain why after talking about something else.
I think it would be much better if you did not introduce a new
configuration merge.options which is not consistent with everything else
to begin with.
Instead, if your addition was literally to allow saying things like this,
it would be much easier to understand.
[branch "*"]
mergeoptions = ...
remote = origin
rebase = true
[branch "frotz"]
mergeoptions = ; nothing
rebase = false
[branch "nitfol"]
remote = xyzzy
When on branch 'nitfol', because there is an overriding "remote" defined,
we would not look at branch.*.remote and fetch from xyzzy instead of
fetching from the default origin. Because there is no "rebase" defined
for that branch, we would use branch.*.rebase=true from the fall-back
default.
When on branch 'frotz', because you have an explicit mergeoptions that
says "I do not want any", it would override whatever is defined for the
corresponding fall-back default branch.*.mergeoptions.
Having explained that I think branch.*.mergeoptions is syntactically nicer
and more extensible as the UI to the end user, let's discuss the
"cumulative" aspect. In the following, I'll keep using branch.*.$option,
but you can read it as if I said merge.options and the discussion is the
same.
There are two reasons why you as an end user specify a concrete value
(e.g. "empty") for a concrete branch name (e.g. branch.frotz.mergeoptions).
One is because you know the current value set to the fall-back default
(e.g. branch.*.mergeoptions) is not suitable for this particular branch.
Another is because you know you may want to change the fall-back default
sometime in the future, and you do not want that to affect your setting
you are making for this particular branch today.
For the purpose of the first reason above, if you allowed cumulative
option, the end user needs to inspect branch.*.$option and come up with a
countermanding set of options to set to branch.frotz.$option. If there is
no cumulative option, the end user does not have to worry about what
branch.*.$option says. Non-cumulative is simply easier to understand.
For the purpose of the second reason above, when the user has to update
branch.frotz.$option because some external situation changed (e.g. the
user used to be an e-mail contributor, but now gained "push privilege";
the user became the primary maintainer; etc.), the same argument on
maintenance burden as above holds. To update branch.*.$option, you need
to inspect every branch.$specific.$option (or lack thereof) as well in
either way.
So overall, cumulative configuration tend to be more cumbersome for the
end user to manage.
You cannot draw a direct analogy with the command line options, which is
used as a single-shot override by nature. The user knows what usually
happens when he says "git pull" while on branch 'frotz' without options,
and countermanding specific aspects (but not necessarily others) of the
operation for this single invocation. Because the configuration values
are set so that the user can set-and-forget the exact syntax to invoke
each feature, cumulativeness between configured default and command line
override makes more sense.
--
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
