Backport #39728 by @silverwind
Since https://github.com/go-gitea/gitea/pull/39703, Gitea fails to start
when its gitconfig holds a `gc.reflogExpire` other than `90` (e.g.
`30.days`), because `git config --unset-all` exits 5 when no value
matches. Value patterns were also unanchored regexps, so `90` also
removed `90.days`.
- Match values exactly in `configUnsetAll` and `configAddNonExist`
- Treat "nothing to unset" as success
- Use `--replace-all` in `configSet` so a key with multiple values no
longer fails startup
Co-authored-by: silverwind <me@silverwind.io>
Backport #39703 by @silverwind
Gitea's default `gc.reflogExpire = 90` is parsed by git as
`1990-<month>-<day>`, currently `1990-10-09`, so reachable reflog
entries never expired.
Since git 2.54, auto maintenance runs its reflog-expire task in the
foreground of every push, and its trigger ignores reachability, so busy
repos rerun `git reflog expire --all` on every push without pruning
anything, stalling large repos for over a minute.
- Stop setting `gc.reflogExpire` so git's own defaults apply, and remove
the `90` written by earlier versions
- Treat the legacy `[git.reflog] EXPIRATION` as days, as documented
The next push to each repo prunes the accumulated entries once.
Fixes: https://github.com/go-gitea/gitea/issues/39693
Co-authored-by: silverwind <me@silverwind.io>
This is really a follow-up to
[#38148](https://github.com/go-gitea/gitea/pull/35305) , instead of
having specific mappings of options for git configurations, just honor
any user-provided gitconfig. I include a test which points out the
specific config I have which was previously not honored, but more
generally this means that gitea now only *adds* new gitconfig and never
overwrites any config provided under `[git.config]`.
---------
Signed-off-by: Royce Remer <royceremer@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>