search

OCA / l10n-finland

GNU Affero General Public License v3.0
4 stars 20 forks source link

[14.0] l10n_fi_business_code accidental push #40

Closed jarmokortetjarvi closed 3 years ago

jarmokortetjarvi commented 3 years ago

I managed to mess up an push directly to 14.0 branch :disappointed: https://github.com/OCA/l10n-finland/commit/a5e2a7feb51970a98366757a8b912917411500d6 Any ideas what to do about this?

The comparison is here https://github.com/OCA/l10n-finland/compare/13.0...jarmokortetjarvi:14.0-mig-l10n_fi_business_code?expand=1

I've managed to do this once before and asked about branch protection then, but apparently we can't protect master branches as it would prevent bots from working. I really dislike having the possibility to push directly to the master.

aisopuro commented 3 years ago

@jarmokortetjarvi I think that since we're maintainers here (I think?) we get to decide which of these approaches to take:

  1. Keep committing until done. If the current 14.0 branch includes code or features that are not working, we could just keep working on them until they are ready to be in a mainline branch.
  2. Force-fix. If you identify the commit that 14.0 should be at, you can reset your local branch to that commit using git reset --hard and then use git push --force-with-lease to "carefully force push" the reset. I suspect this may be entirely not OK: this is an open-source public repo and force pushing in that context is probably never OK.
  3. Revert. Like the reset, but we instead add commit(s) that revert whatever changes were not ready for prime-time and push those to 14.0. It introduces a little noise maybe to the history, but would be very backwards-compatible in case anyone's had the time to pull the "mistaken" 14.0 already.

Judging by the diff you linked, to me it kind of seems like number 1 is our preferred option. Mistakes happen, but the migration seems to have been pretty straightforward anyway. I have no objections, provided that we don't lose any commits, which it seems we won't.

jarmokortetjarvi commented 3 years ago

I agree the number 1 would be best in this case.

I'd really rather not force-push anything here, and reverting makes unnecessarily confusing commit noise.

I'll double-check if there was something more to do with the migration and figure out how to locally prevent myself from repeating the same mistake, as protecting branches or pre-commit no-commit-to-branch not an option.