1

Scenario:

  • You work in a CI/CD corporate environment where changes by several different teams get merged into master all the time.
  • Sometimes, one of the merges has to be reverted, so that the release based on master goes out successfully -- because one of the teams pushed a "merged into" commit that contained a bug.
  • When the team starts working again on the broken feature (to write the fix) the first action is to revert the revert, in order not to mess with master's history.

Problem:

I've noticed that the "double revert" makes it look like the one person who did the second revert wrote the entirety of the feature which got originally reverted, even when it is made of many commits by many people.

Let's say the feature was made of 100 commits.

  • Cherry picking is quite complicated.
  • Also you can't do a rebase because that would require a force push to master, which is forbidden .

Question:

Is there a lightweight way of maintaining the original authors?

Improve this question
5
  • 2
    Perhaps this is a tongue-in-cheek response, but...perhaps the solution is to stop using a friggin' monorepo! If the underlying problem is that cherry-picking is quite complicated and rebasing is a challenge, then address that problem. Stop (not just you, the whole friggin' industry) trying to shoe-horn git to be the solution to deployment problems. Use git for version control, and keep the repos small and easy. Use something else to manage the repos. It's 2024 and package management is worse than it was in 1995! Commented Nov 20, 2024 at 15:17
  • @WilliamPursell you are right. I think in this case the repo still has a reasonable size, it was just an unfortunate series of circumstances: several teams working exactly on the same area, plus a surprise bug, plus an unusually high number of commits (a very fast-paced week) Commented Nov 20, 2024 at 15:19
  • 1
    There is trick to re-merge the same branch again. It uses git replace --graft temporarily to let Git think it has never merged the branch. Commented Nov 20, 2024 at 21:46
  • @j6t If you turn that comment into an answer (link to your other answer and copy-paste its text as per stackoverflow's practices) I can upvote it and/or mark it as the correct answer. Commented Nov 21, 2024 at 10:21
  • 1
    @jeancallisti Thanks, but kindly hop over to the linked answer and up-vote it. That is more in the spirit of SO. Commented Nov 21, 2024 at 11:07

2 Answers 2

Reset to default
0

The only way I know is to revert the revert. Or to reapply the original change. [1] In the case of merge commits that is.

Because reverted merges have to be treated with some care.

With this:

git revert --mainline 1 <faulty> ... git revert <revert>

You will end up with this (top is most recent):

  • d68cbf7a7d0 Reapply "Merge branch 'tb/multi-pack-reuse-dupfix' into next"
  • ...
  • f04a3d85c83 Revert "Merge branch 'tb/multi-pack-reuse-dupfix' into next"

You can then point to the original merge commit in the reapply/revert-of-revert commit message:

Reapply "Merge branch 'tb/multi-pack-reuse-dupfix' into next" The dust has settled. Reapplies: 32792297e5 (Merge branch 'tb/multi-pack-reuse-dupfix' into next, 2024-11-16)

Not using revert

I use reverts for small screwups. Little obvious (I think) mistakes which, when removed, will make the otherwise obviously correct enough snapshot correct again.

But you don’t need to revert or make any other oh-whoops commits: you can instead deploy a previous commit.

Given this history (top is most recent):

  1. (empty slot)
  2. Good commit (deployed)
  3. Good commit
  4. Bad commit
  5. Good commit
  6. Good and well-tested commit

You deployed (2) but found out that (4) was fishy. So you make the revert:

  1. Revert (4) (deployed)
  2. Good commit
  3. Good commit
  4. Bad commit
  5. Good commit
  6. Good and well-tested commit

Now you have the problem of potentially reverting a large (100 commits! e.g.) merge commit. Which might just be reapplied again right after since you want to fix the problem more surgically. Okay but let’s assume that the revert causes no merge conflicts. Then you just have massive version control churn.

But there is another problem. Is (1) a well-tested commit? No it isn’t. The snapshot of (1) might be completely untested. Yeah (4) had some bad stuff in it. But it might have been what held (3) and (2) together—that hasn’t been tested.

The only good and well-tested commit here is (6). You can deploy that:

  1. (empty slot)
  2. Good commit
  3. Good commit
  4. Bad commit
  5. Good commit
  6. Good and well-tested commit (deployed)

There’s nothing stopping you. Either tag that or just use the hash—a SHA-1 hash is going to identify your deployment uniquely just fine.

Caveats to deploying previous snapshots: stateful changes

You can’t deploy a previous version if you did stateful changes to the application in one of the intervening commits. For example:

  1. Revert (4)
  2. Good commit—deployed
  3. Good commit & DB updates
  4. Bad commit
  5. Good commit
  6. Good and well-tested commit (deployed)

(3) here throws a wrench in things. Maybe you changed some DB tables. The application is going to get confused if you reset to a previous version.

Notes

  1. According to Git:
    • Revert-of-revert = reapply
Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

Using git cherry-pick keeps the original author of the commit that's cherry-picked.

Example:

git cherry-pick <commit-hash-to-be-reapplied>
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.