git: Configuration file is replaced on update

[Bachsau (Bachsau)]

Everytime an update for git is installed, it replaces the /opt/local/etc/gitconfig file with a default one. Customized configuration files should not be overwritten.

[cjones051073 (Chris Jones)]

Whilst I don't dis-agree, you can side-step the issue by placing your customisations in your user-level config file $HOME/.gitconfig.

[Bachsau (Bachsau)]

Replying to cjones051073: I discovered that this only affects the "credential_osxkeychain" variant. Since I'm not using that, I removed the variant, and without it, no configuration file is installed, but this should still be fixed. My user-level configuration is linked to a cloud-synced folder, which is why OS specific settings go in the system-wide file.

[Chris Jones <jonesc@…>]

In 6d7892ca5d5b7e48316ca1d6a86db80b0c1f006c/macports-ports (master):

git: Extend port notes regarding MacPorts provided config file
MacPorts provided config file will be overwritten on port upgrades,
so advise user not to place any personal customisations here and
instead use their personal $HOME/.gitconfig file
See: #63953

[cjones051073 (Chris Jones)]

Briefly looking into this handling maintaining user specific changes across port upgrades would be very complex and beyond I think the scope of what is reasonable to expect, particularly as given there is an easy alternative that would work just fine for the vast majority of users which is to just use their personal configuration file. Hence the above. Those that still wish to do this can, but will need to expect to have to maintain their changes across port upgrades themselves.

[danielluke (Daniel J. Luke)]

We could also handle this like (almost) every other config file - if it's not present, put one there with the values you want to set for the user - otherwise just install it with a suffix (.sample, .dist, .example are all in my $prefix/etc). You can out port notes to remind users to update their config.

[cjones051073 (Chris Jones)]

Conceptually for me this is not that different to what happens now. In the (not recommended) case that a user fiddles with the macports provided config file, after an update they have to check to make sure it is how they want. The difference is the behaviour as it is ensures the variant that requires the configuration file will work, wheras with what you propose that might not be the case. So for me its better the way it is.

[danielluke (Daniel J. Luke)]

You should reconsider your stance since blowing out the user configuration on upgrades is unexpected behavior and we consider it a bug for every other port whenever it's been discussed on the mailing list. Even if both strategies are roughly equivalent (I'd argue that they aren't), the fact that other ports all use one method should make it the preferred option.

[danielluke (Daniel J. Luke)]

See also ​https://trac.macports.org/wiki/PortfileRecipes#configfiles

[cjones051073 (Chris Jones)]

Well, its not my port to maintain, so I guess I will leave it to them to decide how to proceed.

[Bachsau (Bachsau)]

This is a very bad attitude. Configuration files are there for a reason: To allow the user to configure things. Otherwise, the changes could just be compiled in. Besides that, on managed multi-user systems (even if that might not be very common for Macs), one can not maintain system defaults in the per-user files, which is why system-wide configuration files exist. A good package manager would not even make this port specific but refrain from overwriting anything in /etc that's different from the previous version's package contents as a general rule. Special handling is not needed. Merging things or saving .dist-files are comfort features that are nice to have, while replacing user-defined configuration files is destructive!

@cjones051073 I expect to have to maintain my changes across updates, but I can't do that, when everything is lost. Additionaly, most software does not require changes to configuration files on every update. Git does not. Compiled-in defaults rarely change, and git happily accepts even the most ancient of configurations. It just reads what it understands and ignores any settings that might have been removed. The vast majority of users would also not have problems if everything unchanged is updated properly, while for those who do changes, replacing the file definitely DOES break things. Suddenly I accidently commit files to my repos that should be ignored (like "Icon\r"), aliases stop working, and unicode filenames get decomposed. Closing bugs as "wontfix" is just another way of saying: "I don't care and I'm too lazy to work on it."

[herbygillot (Herby Gillot)]

Proposing a fix to this behavior with this PR: ​https://github.com/macports/macports-ports/pull/13259

This changes things so that right when the git port is about to be activated, it checks whether the gitconfig exists before creating a new one with the osxkeychain configuration. If the file already exists, then it will not overwrite. Instead, it will check the file contents to see whether the desired configuration is already present in the gitconfig, and only adds the configuration if it isn't.

[herbygillot (Herby Gillot)]

Merging this shortly if there are no objections.

[herbygillot (Herby Gillot)]

In 69b7650c28fb31e7e96ce638dbc31aba878df309/macports-ports (master):

git: do not overwrite the system-wide gitconfig when adding configuration for the osxkeychain credential helper

If the gitconfig does not exist, then it will be created. But if it *does*
exist, then the file will be checked to see whether it already contains the
desired config, and if it doesn't, the configuration will be appended to the
already existing file.

Fixes: #63953

[ryandesign (Ryan Carsten Schmidt)]

Since you are changing what the port installs and are changing what it does at pre-activate time, you must increase the port's revision. Not having done this means that git fails to activate now:

​https://build.macports.org/builders/ports-10.8_x86_64-builder/builds/69957/steps/install-dependencies/logs/stdio

Error: Failed to activate git: Image error: /opt/local/etc/gitconfig already exists and does not belong to a registered port.  Unable to activate port git. Use 'port -f activate git' to force the activation.

[ryandesign (Ryan Carsten Schmidt)]

Herby, didn't realize you weren't Cc'd yet. Please read comment:18.

[herbygillot (Herby Gillot)]

Understood - bumped: [863559d6a4b50d60b58cf3261aba9cc99781ea33/macports-ports]