Added config option.

[ShogunPanda]

This PR adds two new options:

1. --config <PATH>: Can be used to load a config file different from ./.gitconfig. The loaded file MUST use the same format.

2. --features-first: (bool) When enabled, this options gives features priority towards the default delta section. For instance, if we have the following .gitconfig file:

   [delta]
   pager = DEFAULT
   
   [delta "feature"]
   pager = FEATURE
   

   With the current delta (or, if this PR lands, by default) the final resolved value for the pager, even if the feature feature is enabled) would be DEFAULT. With the new option, the final resolved values becomes FEATURE.

Fixes #1301.

[dandavison]

Nit: if you can find a nice way of doing it I'd prefer to avoid duplicating the

Self::from_clap_and_git_config(env, Self::command().get_matches(), git_config, assets)

call and instead compute git_config either from the custom file or accepting the passed-in value.

[ShogunPanda]

Done. What about now?

[dandavison]

I'm not yet sure that I agree with --features-first, so that one is at design stage, not PR stage. Can you give examples of some problems that you would solve with --features-first? I suspect they can be solved with existing mechanisms but I may be wrong.

If you'd like the --config part of this PR to merge before resolving that discussion then you could split it out into a separate PR.

[ShogunPanda]

I'll address the code suggestions this evening. Thanks for the hints: I'm not a Rustacean yet but I'm trying to ;)

About the feature-first flag, I might just be me misunderstanding features at all.
When I looked at them I kinda interpreted as a way to "override" the main delta section. So basically the main delta was supposed to behave as a "user default" and a feature might override it.

But apparently the delta section is always the source of truth if present and features can only backfill it.

My new option instead enables the way I initially interpreted. The way I find is useful is when in the gitconfig you set a value in the delta section and eventually you want to overwrite or "unset" (in the case I mean overwrite by setting the original default value) in a feature and you don't want to maintain separate files.

[ShogunPanda]

Moreover, one important remark: the new option is a opt-in (and disabled by default ) so existing users are not affected at all.

[dandavison]

When I looked at them I kinda interpreted as a way to "override" the main delta section. So basically the main delta was supposed to behave as a "user default" and a feature might override it.
But apparently the delta section is always the source of truth if present and features can only backfill it.

I think you're right that behavior here is a little bit surprising, but there is a way of doing what you want that I and others use. Basically, this doesn't work (as you know):

[delta]
file-added-label = from default section

[delta "my-feature"]
file-added-label = from my feature section

But this works:

[delta]
features = my-defaults-feature

[delta "my-defaults-feature"]
file-added-label = from my-defaults-feature

[delta "my-feature"]
file-added-label = from my-feature

e.g. with (using your new option)

delta --config /tmp/delta.config --features=my-feature --show-config

or with

export DELTA_FEATURES = '+my-feature'

[ShogunPanda]

Oh, I see.
So, in other words, everything that I want to be "overwritable" from a feature must be extract off the main delta in a feature and eventually that feature can eventually be loaded by default in the main section. Am I right?

In that case you are right, my use case is redundant. I'll remove from the PR. Eventually, I'll just double check the docs and add this use case explicitly so that other people don't get in my same mistake.

[dandavison]

Yes that's right. Improving the docs would be great, and I'm open to code changes that make the behavior more natural/coherent/intuitive if it doesn't change things too radically and feels like it's fixing a bug. But I'd prefer not to add additional options parameterizing the config resolution behavior since it will get very niche!

[ShogunPanda]

I agree, maybe supporting both idea is too much.

Not sure which is the more "natural". TBH the current one didn't sound natural to me, but it might just be me.

Probably since this is only relevant when using features, and as probably nobody can use (or get to know about them) features without reading the docs, just improving docs might be enough.

As you have seen, changing behavior it's only a matter to move an if block.

I'll remove the new option anyway. Just let me know if you want me to change the behavior or update the docs.

[ShogunPanda]

As promised, I've handled the two code issues.
I also removed the features-first option and improved the documentation for the use case that confused me.

@dandavison Do you think are we good now?

[dandavison]

I think the first two uses of the word "value" here are synonymous with "option" in earlier lines?

[dandavison]

Don't worry I just made the minor edit I was going on about and will merge now.

[dandavison]

Awesome, thanks! I think this will be useful.