maintain world git config via template, including disablement option, including disabling gpgkey by default

[MeeniMc]

I need to have gitconfig contain the following option for other projects, but that conflicts with using fastback on that same computer

.gitconfig:

[commit]
  gpgsign = true

This causes the following error (backup is staged, but not committed).

[11:10:07] [Server thread/INFO]: Starting backup
[11:10:07] [pool-3-thread-4/INFO]: Preparing local backup snapshots/514682d2-7ad6-4bf9-bbae-49044e2fa786/2022-10-24_11-10-07
[11:10:08] [pool-3-thread-4/INFO]: Disabling world save for 'git add'
[11:10:08] [pool-3-thread-4/INFO]: Adding 755 new or modified files to index
[11:10:15] [pool-3-thread-4/INFO]: World save re-enabled.
[11:10:15] [pool-3-thread-4/ERROR]: Command execution failed.
org.eclipse.jgit.api.errors.ServiceUnavailableException: Signing service is not available
    at org.eclipse.jgit.api.CommitCommand.sign(CommitCommand.java:328) ~[org_eclipse_jgit_org_eclipse_jgi206071550-r-f0955f5ce674565a.jar:?]

Ideally, gpgsign should be ignored automatically (since there is really no point in signing the backups, and using the signature may require interactive password input)

[pcal43]

Seems to me the solution here is to either

• not set gpgsign = true in your global git config; set it only in the projects that need it, or
• set gpgsign = false in the git config of your minecraft worlds

[MeeniMc]

Solution 2 is workable, but why not having this set by default when the repo is created on the first backup?

[pcal43]

Couple reasons

• There are dozens of git config settings that probably don't make sense in a minecraft backup. I'm reluctant to get into a guessing game of whack-a-mole.

• In general, my expectation is that folks who understand what a global git config is are able to manage this sort of thing. In fact, I think more sophisticated users prefer it when tools like this just get out of their way as much as possible.

So, I dunno. I do plan to add a default config that follows a similar strategy to .gitignore (maintained by the tool with configurable disablement of updates for advanced users). I suppose there's not a lot of harm in adding gpgsign = false to it. But I am wary of a slippery slope here.

[jan-Sanku]

I'd like to bump this. While it's true that users who know what a git config is will be able to figure it out eventually, this should still be worked on, because it leaves the repo in a weird state (reading the author's message, apparently it's staged but not committed?)

I personally couldn't come up with a way of fixing it, other than deleting the repo and setting it up again from scratch. (obviously not the right solution, but I don't know better)

Either fix it by including a config (you don't really have to go down any slope, just include this 1 line for now, and add anything that other users find down the line when or if it happens. easy enough for most users to just PR), or at least document the issue somewhere in the docs. Let users know that global configs might mess with this, specifically this one, and also tell users how to fix it when it happens (including repairing the repo).