Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#63953 closed defect (fixed)

git: Configuration file is replaced on update

Reported by: Bachsau (Bachsau) Owned by: ci42
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: cjones051073 (Chris Jones), mascguy (Christopher Nielsen), ci42, herbygillot (Herby Gillot)
Port: git

Description

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.

Change History (20)

comment:1 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: set to ci42
Status: newassigned
Summary: Configuration file is replaced on updategit: Configuration file is replaced on update

comment:2 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by cjones051073 (Chris Jones)

Cc: cjones051073 added

comment:4 in reply to:  3 Changed 3 years ago by 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.

Last edited 3 years ago by Bachsau (Bachsau) (previous) (diff)

comment:5 Changed 3 years ago by 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

comment:6 Changed 3 years ago by cjones051073 (Chris Jones)

Resolution: wontfix
Status: assignedclosed

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.

comment:7 Changed 3 years ago by mascguy (Christopher Nielsen)

Cc: mascguy added

comment:8 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by 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.

Last edited 3 years ago by cjones051073 (Chris Jones) (previous) (diff)

comment:10 Changed 3 years ago by 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.

comment:12 Changed 3 years ago by cjones051073 (Chris Jones)

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

comment:13 Changed 3 years ago by 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."

Last edited 3 years ago by Bachsau (Bachsau) (previous) (diff)

comment:14 Changed 3 years ago by danielluke (Daniel J. Luke)

Cc: ci42 added
Resolution: wontfix
Status: closedreopened

comment:15 Changed 3 years ago by 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.

comment:16 Changed 3 years ago by herbygillot (Herby Gillot)

Merging this shortly if there are no objections.

comment:17 Changed 3 years ago by herbygillot (Herby Gillot)

Resolution: fixed
Status: reopenedclosed

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

comment:18 Changed 3 years ago by 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.
Last edited 3 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:19 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: herbygillot added

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

comment:20 Changed 3 years ago by herbygillot (Herby Gillot)

Last edited 3 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)
Note: See TracTickets for help on using tickets.