Re: [PATCH 3/3] builtin-merge: add support for default merge options

Jay Soffian <jaysoffian@gmail.com> writes:

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.