Code has diverged because of force push, blocking further NonGNU ELPA releases

[monnier]

The scripts building the iedit tarball for NonGNU ELPA can't update to the new version because the code upstream has diverged from the code in nongnu.git:

% make fetch/iedit
emacs --batch -l admin/elpa-admin.el -f elpaa-batch-fetch-and-show "iedit"
Fetching updates for iedit...
Upstream of iedit has DIVERGED!

  Local changes:
d62dc47575  victorhge@gmai..  Revert "Add license file with GPLv3"
3bd4c15e3d  stefan@marxist..  Add license file with GPLv3

  Upstream changes:
699e179dac  victorhge@gmai..  New version 0.9.9.9.9
48ab9e4be2  victorhge@gmai..  Add missing ;;;###autoload
b13f05b9f1  victorhge@gmai..  New feature: switch from rectangle-mark-mode to iedit-rect mode

%

Could you merge the d62dc47575 commit into the upstream branch, so that the nongnu.git can fast-forward to the upstream branch again? You don't need to make any file changes, but we do need the metadata merged.

E.g. you could do something like:

git fetch git://git.sv.gnu.org/emacs/nongnu.git elpa/iedit
git merge -s ours d62dc47575

[victorhge]

So will this happen again if I do a force push next time?

[victorhge]

Would it be possible for you to move nongnu local branch backward by two commits? git reset --hard HEAD~2

[monnier]

Victor Ren [2022-02-15 23:11:27] wrote:

So will this happen again if I do a force push next time?

Of course. Every time you force push, you impose on every one tracking your branch to take extra steps. So the general rule is to never ever force push onto a public branch.

(Of course, there can be exceptions, such as when you absolutely need to force push because you included a file which you're not allowed to distribute, or when the branch is officially announced as something like a throw away work-in-progress, ...).

It's worse for nongnu.git, tho:

• it's not only used internally, but other people track nongnu.git as well, so any "extra steps" we take in nongnu.git can impose those same "extra steps" on those who follow nonngnu.git.
• some of those "people" who track nongnu.git aren't people but automated systems, which then need to be manually fixed.

[monnier]

Victor Ren [2022-02-16 00:34:19] wrote:

Would it be possible for you to move nongnu local changes backward by two commits? git reset --hard HEAD~2

It's a lot of work to do that on all the places where it would need to be done. So, no, not really.

Why do you want to avoid something like git merge -s ours d62dc47575?

[victorhge]

Just wanted to get more understanding of this problem. It seems I have to figure out a branch strategy to avoid this kind of issue in the future.

I have merged d62dc47575 into the master branch. Let me know if it works for nongnu.git.

[monnier]

Just wanted to get more understanding of this problem. It seems I have to figure out a branch strategy to avoid this kind of issue in the future.

Personally I use 2 branches: main and wip. So I push to wip any time I want (including with completely broken code when I have to move from one computer to another in the middle of a refactoring), including force pushes and such. I then merge wip into main every once in a while.

More importantly: I don't pay too much attention to whether the history is clean. Instead I focus solely on whether the history has all the information I may need.

So I may rebase on wip to improve the history and then merge the result to main: this leaves the bad history around if I made the mistake to push it to main but I find it a small price to pay for the smooth behavior of downstream branches.

I keep hoping that Git will grow some way to label some paths in the history as "deprecated", tho, so I can have my cake and eat it too.

[monnier]

I have merged d62dc47575 into the master branch. Let me know if it works for nongnu.git.

Thanks, it's all good here.