Maintain custom settings while updating with a `git pull`

[Efreak]

This allow users to change settings.ini and keep their skin up to date via git pull (I use git pull because it makes it easier to keep it in sync across multiple computers that happen to already have git installed). With this solution, both users and developers can have their own local modifications to settings.ini as well as the defaults. The changes to your local copy won't be pushed to the repo (in dev case) or overwritten by a pull (user case).

Formerly, I had to save my changes to settings.ini elsewhere every time I updated, or risk losing any changes that were made to the default settings.ini (ie, new tweaks, tweaks being removed, etc...)

[somini]

The only problem with this is that makes the skin unusable when you git clone it somewhere. You have to copy the template into the proper place first and then change some settings (if you wish).

There should be a way to solve this, I just have to test something...

[somini]

Hmm, this seems to be working. I got a first implementation on branch https://github.com/somini/Pixelvision2/tree/pull/18

[Efreak]

You might be able to move the includes from the bottom of settings.ini to the top of steam.styles. Not sure if it will break when you try to include a settings.ini that doesn't exist, though.

[somini]

Hrm, this is more complex than it seems at first glance. You can't just include non-existing files or it breaks.

[somini]

Yup, this seems nigh-impossible, you can't have files in the repo untracked, so either the skin breaks when you just clone the repo until you create an empty file, or git pull rewrites your settings.

My hacky hack is the somini branch, with my settings applied. Everytime the master branch moves, I just do:

git checkout master
git pull
git checkout somini
git rebase

As long as settings.ini keeps roughly the same, it Just Works.

[Efreak]

^Weird commits crap is weird. I merged your repo with my fork and apparently I'm committing things twice?

Does this work? I basically re-added settings.ini as well as a default version. It can be changed, but changes will be ignored. More accurately, git-status will whine that settings.ini has been changed, but it will allow you to push/pull anyways, without making any changes to the file.

Edit: this doesn't work. You might be able to tell users who care about this to have a settings.ini.bak file as well. You can then add this file to .gitignore. And you can add a smudge filter to .gitattributes (in the local repository) to overwrite the newly-overwritten settings.ini with the backup copy. Of course, this would require users to have two copies of their settings.ini and make any changes to both of them... I had initially tried using a post-merge hook, but you can't add these to the repository; I think you can add .gitattributes to the repository.

[CaptainMagma]

I believe the skin updater tool provided in a pinned discussion in the group allows for the user to keep their saved PixelVision settings after updating. Although, I'm pretty sure the program is exclusive to Windows users only.

[somini]

Yeah, @CaptainMagma has it right. If you want to use only git, and don't want the hassle of keeping a tracking branch, here's another way: Everytime you want to update the skin and have changed the settings, just run

git stash save
git pull
git stash pop

[Efreak]

I'm just editing the config file now and running git update-index --assume-unchanged settings.ini when I'm done; I believe that as long as you only append to the file in the repo and don't modify tweak descriptions, it should continue to update correctly for anyone using this method. Unlike stashing, this command only needs to be run once when you actually change the file, not whenever you update it (so you could update through the GFW gui, for example).

[somini]

Sorry for taking so long to answer this, I was away for this past few days.

Wow there, that's a frightening hack, and using the git plumbing to boot. It basically skips the check to see if the file has changed. I'm pretty sure that will overwrite your changes if you update the repo. I still have to test this, and if it does work, I'll update the README.

[Efreak]

The first two answers here might help. Looks like maybe skip-worktree might be better?

[somini]

I'll be damned, it works! skip-worktree, I mean. It keeps the git status clean, so you can pull without committing your changes to the settings, the only manual intervention needed is when the settings change, which should be a rare event.. There are some confusing messages when the upstream settings changes, but nothing that can be fixed with a good README.

Wanna try to write it? If not, I'll take a shot at a first version, probably this weekend.