0

In my organization, we have a commit hook that rejects commits if ANY commit in the tree has an author value that doesn't match a particular pattern. This is normally used to catch faulty commits before they are merged to a target branch. The fact that it also scans existing commits in the target branch usually doesn't matter, as the hook prevents those "tainted" commits from being merged.

However, the people who maintain that hook had a production problem yesterday that resulted in all developers being blocked. So, they turned it off until they could figure out why it was breaking.

I was immediately concerned about this, because this meant that it's possible that a developer who wasn't paying full attention could possibly merge one or more commits with a bad author value.

As I expected, my concern was realized, as one developer managed to do this.

We have an annoying workaround that can make the hook pass the validation even in the presence of some "tainted" commits in the target branch (requires creating the source branch in the central repository (BitBucket) instead of the local repo), but I really don't want to have to do that, or have all the other developers do that.

I really want to just fix the already merged commits.

So, that means interactive rebase. I understand the process, even how to change the author value for each commit. What I'm concerned about are the warnings about "rewriting history", and whether that can break anything. Interactive rebase is fine when you're working on a pull request branch that is only used by you, and isn't merged to the target branch yet. I'm talking about doing this on "master".

However, the ONLY change I'm going to make to any of these commits is the author value. If that is the only change I make, what risks are there? Does this remove the main "rewriting history" risk?

Romain Valeri
  • 19,645
  • 3
  • 36
  • 61
David M. Karr
  • 14,317
  • 20
  • 94
  • 199

1 Answers1

1

When you rewrite your commit history, and force it on the remote acting as the central repo, this operation doesn't change the refs that other people currently using this repo have stored in their own local copies.

What does it mean in terms of consequences?

They might have branched their own feature branches (with work on it) from a an old ref from master which does not exist any more in its now-rewritten history. At this point, let's note that all history past the oldest rewritten commit will be itself rewritten, as it uses the ref of its parent in the production of its hash, so even if you modify only one commit, all history is rewritten from this commit up to the most recent commit.

So they'll be unable to push anything to a remote which doesn't recognize their versions of the repo history any more. (also, beware of breaking tags and signed commits, thanks phd for the reminder)

To remedy to that, they'll have to backup their current branches, restore their local versions of master to the new version, then rebase/cherry-pick their work on top of it.

So team communication is key here. If someone is unaware of the process and (...since he's getting refused when he tries to push...) force-pushes his old ref at some point in the process... well, you get the (scary) picture. Gather every user around a discussion on this, and when everyone agrees on the same course of action, this will become a solvable case.

(To go beyond these general principles, take a look at torek's answer here which is very informative on the subject.)

Romain Valeri
  • 19,645
  • 3
  • 36
  • 61
  • I'd also add that rewriting history could break tags and signed commits. – phd Mar 07 '19 at 22:16
  • @phd True. I tried to stay on the general principles, but this is important, I've edited to add it. – Romain Valeri Mar 07 '19 at 22:23
  • So to be clear, you're saying it doesn't matter if the only thing I'm changing in these commits is the author? – David M. Karr Mar 07 '19 at 22:49
  • @DavidM.Karr Wow I'm sorry I must have be much less clearer than I wanted to. I did not want to mean that *at all*. Changing huge chunks or just one author name both have just the exact same consequences I described here I'm afraid... every commit made after the one you modify will have a different parent, so a different hash... – Romain Valeri Mar 07 '19 at 22:53
  • I'm afraid I probably misstated my comment. I wasn't implying that I thought you were saying just changing the author would have no impact, I was asking you to confirm that it "doesn't matter" what part of the commit you change, even if it's just the author, it would still change the tree, resulting in problems. – David M. Karr Mar 07 '19 at 23:31
  • @DavidM.Karr Oh, ok then, misunderstandings cleared! – Romain Valeri Mar 07 '19 at 23:33