[WEBLATE] Weblate Merge commits are littering our history

[Felienne]

The way Weblate now works is that it creates many many commits in one PR. I have looked into settings on Weblate to make this one commit but I have not been able to find that option.

This would not be a real problem, since we squash merge all commits in a PR into one, making it easier to see changes. But... weblate cannot handle squash merges since then it cannot see which of their commits are captured on our side.

So now we are in a state where, if we want to see what recent changes have been made, you have to wade through a sea of Weblate commits.

Some ideas:

• Explore Weblate settings in more depth to see whether there might be a setting after all
• Run a github action after the merge of a Weblate PR merge to rewrite history and make all commits into one (before is not possible, see above)

[Felienne]

@Mark-Giesen see above. For now I think this might be a more pressing issue than the code snippets. I am not 100% you understand the issue but I could explain it in more depth, and then maybe you can dive into the settings on the Weblate setting.

[Felienne]

@jtwaleson Option 2 might be something you are interested in? It is a step in the direction of a smaller commit history! (But I am not sure if you have experience with github actions, they have a bit of a weird syntax & process.

[Mark-Giesen]

@Mark-Giesen see above. For now I think this might be a more pressing issue than the code snippets. I am not 100% you understand the issue but I could explain it in more depth, and then maybe you can dive into the settings on the Weblate setting.

I don't think I completely understand. Weblate can squash via an Add-On (https://docs.weblate.org/en/latest/admin/addons.html#squash-git-commits), but you would have found that I presume, so why is that not the solution?

[Felienne]

@Mark-Giesen see above. For now I think this might be a more pressing issue than the code snippets. I am not 100% you understand the issue but I could explain it in more depth, and then maybe you can dive into the settings on the Weblate setting.

I don't think I completely understand. Weblate can squash via an Add-On (https://docs.weblate.org/en/latest/admin/addons.html#squash-git-commits), but you would have found that I presume, so why is that not the solution?

No I did not find that, I only checked the basic settings and not the Add-Ons (since I have never added one, I am not sure how that works, esp. with Hosted Weblate) Can we (you, I mean haha) try to enable the Squash Add-on and see what happens?

[Mark-Giesen]

Ah, that's great, then I DID understand and this is an easy fix :-). We do have to make a choice, do we really want 1 commit, or one per file/author/language. Since the title of this issue states this is our history, don't we loose to much by squashing it all in 1? This info will be available on Weblate, that might be enough? By squashing per author we will probably reduce the commits to 3-4 since there are not that many simultaneously working translators. This way we will not loose the author info in our repository, the other options do have that effect. This can be remedied by a commitmessage, but that needs some looking into.

[Felienne]

Ah, that's great, then I DID understand and this is an easy fix :-).

Ok, lets try it!

We do have to make a choice, do we really want 1 commit, or one per file/author/language. Since the title of this issue states this is our history, don't we loose to much by squashing it all in 1?

Good question, but one commit per PR is enough, that is what we do with other PRs also. And we will always be able to see the changes that were made even with one commit. I am not sure of the effect on the history of authors though, so that is something that we will have to check (will the Weblate authors that log in with GitHub see their commit on their history?) Would be a pity if we'd lose that but not as annoying as us seeing 100s of commits in between PRs.

[Mark-Giesen]

Individual author info will be lost unless we squash by author. In other options we could ad a "co-authored by..." line in the commitmessage, but exact author info is lost. Maybe start by squashing per author? I'm not 100% how that would look in the PR.

[Felienne]

Ok, shall we try squash per author then? I am also not sure what that looks like, so let's try!

[Mark-Giesen]

OK, done. By author, rest default settings. This means no special commit message for the squash and trailing comments added when squashing. Let's see what this looks like.

[Felienne]

Ok, now let's hope people will start with a new translation soon (and then that everything works 🤞 )

[Mark-Giesen]

First example is in. Yes, great!

The commit message of the squash commit contains a "co-authored..." line. This will probably be extended to every contributor that is in a commit when we further squash this. I think this is a nice compact PR and we now who to contact when we have questions or tips regarding the translations.

Yes let's keep this as is for now so we retain a bit of the information.

This commit message further contains all commit messages of the separate commits, I think this will get messy, so those individual commit messages might be obsolete?

Yes, if you can remove them, that would be fine! If not, don't worry.

We could write a commit message of our own for the squash.

This will eb done automatically by the GitHub action we have now on other PRs. I will change it when we have a few more commits so we can see how it goes!

[Mark-Giesen]

I think this issue is fixed. The Add-On in Weblate groups all commits per translator. Weblate itself is considered to be an translater in case of prefilling with default language. This prefilling is also done by an Add-On. Since there is no control over the order of Add-Ons, it could happen that the sqaush Add-On has run before the prefill runs. In this case we will see a lot of commits of Weblate, one per file. This is exactly the "mess" described here, but this will be cleaned up by Weblate on the next Push.

See image below to see the result PR, the title look a little random, they are the title of the first commit in the squash. We might want to change this into something more meaningfull. Lets see how this plays out for now.