Re: [PATCH v4] Add default merge options for all branches

[Junio C Hamano <gitster@pobox.com>]

Michael Grubb <devel@dailyvoid.com> writes:

> Well, it certainly serves *my* immediate needs and addresses the
> specific use case that I was originally working on.  Though I think that
> what we've come up with would benefit the codebase in general if for no
> other reason than it lays some ground work for future features...

The discussion was fruitful, I think, and it may have laid the groundwork
at the _conceptual level_.  I however do not think that the approach the
patch takes is generic enough, even if we add globbing of the branch name,
to build on other things that can come out of the future directions the
discussion suggested.

For example, why does "merge.c" hold the parser for "branch.*.*", when
there are a lot more configuration variables that apply per branch that
are totally unrelated to merge?  Don't these branch.*.* variables benefit
from having a wildcard support as well?  If we wanted to add such support,
which configuration parser should be called by many pgorams that deal with
branches (e.g. "checkout -b", "branch", "fetch", ...), and where that
parser should be defined in?  I suspect the answer might be "branch.c",
but I do not htink we explored the uses widely enough to make that
decision yet.

Even if I limit the discussion to "mergeoptions" [*1*], why can I specify
the merge options based on what branch I am currently on, but not based on
what branch I am merging to my current branch?  When on master branch,
should branch.*.mo augument what I have in branch.master.mo, or should it
overwrite it?  I may want to say "all my merges should use --log" and
"when on master I want --no-ff". Should branch.master.mo repeat "--log",
or should the values on the two variables automatically combine? If so in
what order? Am I allowed to say "Use 5 lines of --log" for generic one,
and then "Use 10 more lines of --log than generic" for branch.master.mo,
so that later I can easily change my mind and update branch.*.mo to use 10
lines, and I get automatically 20 lines for the master branch?  If not why
not?

etc.etc.etc....

I am not saying some of these issues are unsolvable, nor we should solve
all these problems right now, but I do not think these issues are
something you are trying to solve with this patch, nor the approach this
patch happens to use was designed with these problems in mind (I certainly
didn't, when I made many suggestions I see in this round of your patch) to
become a foundation to solve them in the future.

The suggestion by Jonathan does not have such a design issue that requires
us to open a huge can of worms right now and potentially result in a
solution that is overengineered to address a wrong problem [*2*].

If it solves the original issue without such downsides, that would be more
preferrable, I think; no?

[Footnote]

*1* I personally think "branch.<name>.mergeoptions" was a mistake.  If it
were separate "branch.<name>.merge-ff", "branch.<name>.merge-log", ... it
might have been more clear what the combining semantics should be.  But
that is not going to change, so I'd rather not to extend the support for
it, until we come up with something more sensible.

*2* For example, globbing to match the current branch name could become an
overengineered solution to a wrong problem, if it turns out that it is not
useful to decide things based solely on the current branch name.