In case you have rewritten history by accident

[tarsius]

I've noticed that you have recently completely rewritten history. However, you did not rewrite tags, so I am guessing you might have done this by mistake. If you did do this on purpose, could you please to it again (after reverting pre-rewrite), making sure you also update the tags?

[rnkn]

Hi @tarsius, Thanks for pointing this out. It was my misguided attempt to resolve my absurd .mailmap. But this is probably a sign I should not have. I've pushed the old history. If you get a moment could you check to see if that resolves the tag problem?

[tarsius]

It was my misguided attempt to resolve my absurd .mailmap.

I had a look. So you've had many email addresses over the years. That's okay, nothing to be ashamed about. ;D

If you get a moment could you check to see if that resolves the tag problem?

Everything looks fine again. Thanks!

[rnkn]

I’d be curious how to accomplish this successfully if you happen to know.

[tarsius]

I've only used git filter-branch, but the new tool is git filter-repo. It has an option specifically to "apply" the contents of .mailmap. But again, I would recommend against doing that.

[rnkn]

Okay I did this because yolo, but please let me know if it creates problems for you.

[tarsius]

Okay I did this because yolo,

The tags still point at commits from before the rewrite.

but please let me know if it creates problems for you.

The problem that it has already created for me is that I had to go and see what has happened. I am not actually using this package but the scripts that I use to maintain the Emacsmirror inform me about such issues. I do this so that I can inform maintainers about potential issues (such as failure to rewrite the tags), to save them and their users from future grief. I have stopped doing this, if just the last handful of commits have been rewritten, but continue to do so if the number surpasses a somewhat arbitrary threshold, and certainly when the history of the mainline got completely rewritten.

I am not a "you shall never rewrite public history" absolutist. E.g., I am perfectly okay with someone, who discovers that there was a typo in their last commit from a few minutes ago, deciding to force push a rewritten commit with the fix. Hell, unless they don't go back more than a dozen commits and a few months, it's still okay to rewrite. As long as no more than a dozen commits and no merges are involved, it is easy enough (but beyond the skill of a "beginner" (which includes most Git users)) to discover and deal with the situation for a downstream who has created feature branches that branch of from the old history.

But complete rewrites should be reserved for exceptional cases, e.g., if you have to do it for legal reasons, to avoid deadnaming someone, or you are breaking up a repository into multiple repositories.

As someone who also has an OCD tendency, I can understand that you want to get rid of the .mailmap. I don't think that doing this is objectively a good reason to cause friction for all downstreams, but if it subjectively necessary for peace of mind, then by all means to it.

That being said, I would encourage you to double check everything has gone smooth before pushing the result (and to afterwards making sure the updated tags really got pushed, e.g., by cloning the repository again, so you can observe what others will get). Also consider that you didn't get this right an the first try, and that you failed on the second try as well, despite my guidance -- given that you had such difficulties, you should anticipate that your downstreams will also run into problems -- is it really worth inflicting that on them?

[rnkn]

Disculpas amigo for the trouble this has caused you!

Thing is I've double checked everything with fresh clones for GitHub and everything shows the tags pointing to the correct commits.

$ git show-ref --tags | tail -n1
89a91513a4ce904a918e87911cab4200049f0db0 refs/tags/v3.7.3

$ git show -s 89a91513a4ce904a918e87911cab4200049f0db0
tag v3.7.3
Tagger: Paul W. Rankin <rnkn@rnkn.xyz>
Date:   Fri Mar 29 12:29:37 2024 +1000

Version 3.7.3

- Add missing options to Save Options command

commit 195fa8670456855b592e76fb495d03cc621ad647 (tag: v3.7.3)
Author: Paul W. Rankin <rnkn@rnkn.xyz>
Date:   Fri Mar 29 12:29:37 2024 +1000

    Add Version 3.7.3 to NEWS.md

$ git show -s 195fa8670456855b592e76fb495d03cc621ad647
commit 195fa8670456855b592e76fb495d03cc621ad647 (tag: v3.7.3)
Author: Paul W. Rankin <rnkn@rnkn.xyz>
Date:   Fri Mar 29 12:29:37 2024 +1000

    Add Version 3.7.3 to NEWS.md

And 195fa8670456855b592e76fb495d03cc621ad647 on GitHub also shows the tag v3.7.3.

Are you sure you're working from a fresh clone?

This is very much a solo endeavour. I double checked the network graph beforehand and there were no current clones apart from Emacsmirror. I don't expect there to be other clones out there so pain should be minimal.

[tarsius]

Uh, yes, you're right the tags are were they are supposed to me. Sorry about that. I'll have to check my mirror tooling, there seems to be a bug related to the pulling of (updated) tags.

This is very much a solo endeavour. I double checked the network graph beforehand and there were no current clones apart from Emacsmirror. I don't expect there to be other clones out there so pain should be minimal.

Understood. My contacting you was more about trying to make sure this wasn't done by accident (that really happens occasionally), than trying to make you reconsider. But then you asked... :grinning:

[rnkn]

All good! Yeah I think it may be that git will rebase a new history with just git pull --rebase but will not overwrite tags unless you git pull --tags -f.

[rnkn]

Can you please let me know when you get this solved? I want to rewrite history of another package that's in Emacsmirror. I'll reopen the issue.

[tarsius]

Can you please let me know when you get this solved?

The "update one package" command's "accept the rewrite" variant, now also forces an update of the tags.

(As before history rewrites, which go beyond a certain threshold, are not accepted automatically, but when I come to the conclusion that the rewrite is intentional, then the command I use to accept it, no longer fails to accept the rewritten tags as well.)

[rnkn]

Awesome. Just letting you know I'm considering rewriting history of olivetti and side-hustle but I'll wait to see if there are any more complaints here first.

[tarsius]

No more objections from me.

[tarsius]

I see you did some more rewrites, and have updated the Emacsmirror accordingly.

The tags of olivetti still point at commits from before the rewrite. I used a fresh clone to confirm this.

The tags of the other repositories have been properly updated.

[rnkn]

Sorry about that. Should be fixed now. Thanks for your guidance on this.