Add-on "Squash Git commits" does not use configured committer user/email

[BhaaLseN]

Describe the issue

We've been using the "Squash Git commits" (set to "per author") add-on since it came about, mainly because we let Weblate regularly commit changes in batch and want to avoid a bunch of commits that all come from the same set of translations across multiple languages.

Recently, not sure when exactly this started, we noticed that the committer switched back from our configured DEFAULT_COMMITER_EMAIL/DEFAULT_COMMITER_NAME (which are also set as user.email/user.name in the repository when I checked data/vcs/GRP/PRJ) back to Weblate <noreply@weblate.org>.

While it's not that much of a problem, we'd rather have consistent emails in there (especially when we have a dedicated one that shows Weblate stuff); and it seemed to have worked before, so I'm not sure if this was intentional or not.

I already tried

• I've read and searched the documentation.
• I've searched for similar issues in this repository.

Steps to reproduce the behavior

1. Configure the "Squash Git commits" add-on with the option "Per author" for a repository
2. Translate at least two languages (or probably also: two files) and wait for the changes to be committed
3. Check the commiter user and email in Git history

Expected behavior

Since both DEFAULT_COMMITER_EMAIL/DEFAULT_COMMITER_NAME are configured in settings.py (which are also set as user.email/user.name in the repository), I'd expect them to be used while committing to the repository.

Screenshots

No response

Exception traceback

No response

How do you run Weblate?

Git checkout

Weblate versions

$ weblate list_versions
 * Weblate: weblate-4.11.2
 * Django: 4.0.3
 * siphashc: 2.1
 * translate-toolkit: 3.6.0
 * lxml: 4.8.0
 * Pillow: 9.1.0
 * bleach: 4.1.0
 * python-dateutil: 2.8.2
 * social-auth-core: 4.2.0
 * social-auth-app-django: 5.0.0
 * django-crispy-forms: 1.14.0
 * oauthlib: 3.1.1
 * django-compressor: 3.1
 * djangorestframework: 3.13.1
 * django-filter: 21.1
 * django-appconf: 1.0.5
 * user-agents: 2.2.0
 * filelock: 3.6.0
 * jellyfish: 0.9.0
 * openpyxl: 3.0.9
 * celery: 5.2.3
 * kombu: 5.2.4
 * translation-finder: 2.12
 * weblate-language-data: 2022.2
 * html2text: 2020.1.16
 * pycairo: 1.21.0
 * pygobject: 3.42.0
 * diff-match-patch: 20200713
 * requests: 2.27.1
 * django-redis: 5.2.0
 * hiredis: 2.0.0
 * sentry_sdk: 1.5.8
 * Cython: 0.29.28
 * misaka: 2.1.1
 * GitPython: 3.1.27
 * borgbackup: 1.2.0
 * pyparsing: 3.0.7
 * pyahocorasick: 1.4.4
 * python-redis-lock: 3.7.0
 * charset-normalizer: 2.0.12
 * Python: 3.9.6
 * Git: 2.30.2
 * psycopg2-binary: 2.8.6
 * ruamel.yaml: 0.17.11
 * Redis server: 6.0.16
 * PostgreSQL server: 13.7
 * Database backends: django.db.backends.postgresql
 * Cache backends: default:RedisCache
 * Email setup: django.core.mail.backends.dummy.EmailBackend:
 * OS encoding: filesystem=utf-8, default=utf-8
 * Celery: redis://localhost:6379, redis://localhost:6379, regular
 * Platform: Linux 5.10.0-10-amd64 (x86_64)

Weblate deploy checks

$ weblate check --deploy
System check identified some issues:

WARNINGS:
?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS setting.
 If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems.
?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True. Unless your site should be available over both SSL and non-SSL connections, you may want to either set this setting True or configure a load balancer or reverse-proxy server to redirect all connections to HTTPS.
?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions.

INFOS:
?: (weblate.I021) Error collection is not set up, it is highly recommended for production use
        HINT: https://docs.weblate.org/en/weblate-4.11.2/admin/install.html#collecting-errors
?: (weblate.I028) Backups are not configured, it is highly recommended for production use
        HINT: https://docs.weblate.org/en/weblate-4.11.2/admin/backup.html
?: (weblate.I031) New Weblate version is available, please upgrade to 4.13.
        HINT: https://docs.weblate.org/en/weblate-4.11.2/admin/upgrade.html

System check identified 6 issues (4 silenced).

Note that the silenced ones are Weblate.W033 for Mercurial, Gerrit and SVN (since we only use Git) plus the default admin.E408

Additional context

According to our Git history, it seemed to have worked back in May of 2021 (where we had weblate-4.7 checked out), but did not work as expected in June of 2021 (where we had weblate-4.9.1 checked out). No translations (or upgrades) in between, so thats the rough window I know of.

Everything else seems to be correct (the Author is set to the change author, and the Co-authored-by tag is also added to the message) in both cases (before and after).

We only noticed this by chance during a bisect that hit Weblate commit and saw the incorrect committer.

Also, I previously had DEFAULT_COMMITTER_EMAIL/DEFAULT_COMMITTER_NAME (note the spelling of COMMITTER with two T's, which is supposedly the correct one over COMMITER with one T) in settings.py, which apparently worked before (since I just changed it to the spelling with one T after double-checking the documentation). I couldn't find any mention in the source code of the spelling with two T's, so that shouldn't affect how things work there.

[nijel]

I didn't find DEFAULT_COMMITTER_EMAIL (with double T) anywhere in our Git history, so these could hardly work.

Anyway, Weblate does write these to the Git configuration, and it then relies on Git to do the correct thing (author is passed on the command line). So, if user.name and user.email match Weblate settings, it might also be a change in Git behavior.

[github-actions]

This issue looks more like a support question than an issue. We strive to answer these reasonably fast, but purchasing the support subscription is not only more responsible and faster for your business but also makes Weblate stronger.

In case your question is already answered, making a donation is the right way to say thank you!

[BhaaLseN]

I wouldn't be surprised if I just typed out COMMITTER (with two T's) by hand, rather than copying it from the documentation).

But it seems weird that the use of that addon uses the incorrect Committer (not Author) in the amended commit. Usually, the Committer is determined by the Git configuration and cannot be modified from the command line (unless certain environment variables are set, mainly meant for reconstructing external history).

As far as I can tell, there is no mention of the noreply email anywhere outside the Weblate sources; everything in data/ is either set correctly (mostly repositories that had been around for a while), or not set at all (mainly the glossary repositories that were auto-created during an update). data/home/.gitconfig has the correct user/email as well. There is no ~/.gitconfig file for the user running Weblate, and there is no system-wide /etc/gitconfig either.

Anything else I could try and look at? I doubt git changed behavior somewhere, in the sense that it pulls a user/email combination out of thin air (without anyone in the git project noticing)

[nijel]

Squash by author does cherry-pick internally, but that should not make a difference.

Can you try looking into the Weblate repository for commits before squashing? You should see them in git reflog.

[BhaaLseN]

Hm, not sure whats going on here, the reflog seems sane:

92a9715c6a HEAD@{11}: checkout: moving from master to master
92a9715c6a HEAD@{12}: reset: moving to weblate-squash-tmp
afde6d0b84 HEAD@{13}: checkout: moving from weblate-squash-tmp to master
92a9715c6a HEAD@{14}: commit: Translated using Weblate (German)
19977139e2 HEAD@{15}: reset: moving to 19977139e2eb769e0e0c8534533e7bbceef33255

...where 92a9715c6a HEAD@{14} is the squashed commit, which currently does have the correct user/email combo. The last one (from a week ago) didn't, and that was certainly after I fixed the spelling of the variables (to only have one T).

I don't understand whats going on, maybe it magically fixed itself over time (after me fixing the spelling of the variables)? Perhaps an old configuration being loaded somewhere (that recycled since), maybe in wsgi, maybe in celery?

I guess we can close this for now, before anyone is getting even more confused than I am right now. 🤷

[github-actions]

The issue you have reported is now resolved. If you don’t feel it’s right, please follow its labels to get a clue for further steps.

• In case you see a similar problem, please open a separate issue.
• If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.