Michael Grubb <devel@xxxxxxxxxxxxx> 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. -- 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