Fixing Bad badEmail: invalid author/committer line - bad email in Git Repository

user_18104535 0
Viewed 248

I have a git repository I am attempting to move to github from bitbucket. This is something I have done before without much difficulty, both using the github importer tool and manually sending up a repo. In this particular case, however, my repository seems to have an issue in its history, which causes github to fail. Notably, when I run git fsck, I get:

git fsck
Checking object directories: 100% (256/256), done.
error in commit 18e86b4bdd4172bfca9f635abfedc84a8bf39bd7: badEmail: invalid author/committer line - bad email
Checking objects: 100% (90779/90779), done.

Git fsck seems to be telling there is a single bad commit, but when I look at this commit, I do not see an obvious reason why it is incorrect (e.g., perhaps a rogue hidden character in the email?). In any case, in order to fix this, the first thing I have tried is to rebase. The tutorial I have attempted to follow seems to suggest to grab the parent commit, rebase, then switch to edit instead of pick in the list. When I do that I am getting a merge conflict:

Auto-merging HourOfCode/SourceCode/Biology.quorum
CONFLICT (content): Merge conflict in HourOfCode/SourceCode/Biology.quorum
error: could not apply 18e86b4bd... Updated Breed method, IsParent method, added Tasks 2 - 6 sample code.

If I try to run the next commands in the tutorial anyway (typical amend commands), I get this:

git commit --amend --author="My Name <nyname@name.com>"
U   HourOfCode/SourceCode/Biology.quorum
error: Committing is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.

Now, I know I could just add the file, but given the impact rebase can have on a repo, it is not clear I have any of this right. I know if such a change goes through everyone will have to re-clone, but my question is, how do I fix this "bad email" into something acceptable and push up this history changing change without damaging my public repository?

github git
1 Answers

Here's the actual commit in question (raw content), and the problem:

$ git cat-file -p 18e86b4bdd4172bfca9f635abfedc84a8bf39bd7
tree 3c1ca25101ec266daa5b7cc8f71b9cbcb5365b73
parent 03f8e6b99fbd996fffe03bda5aeeb17c325893b3
author timkwist <timkwist@hotmail.com> 1402964633 -0700
committer timkwist <timkwist@hotmail.com <> 1402964633 -0700

Updated Breed method, IsParent method, added Tasks 2 - 6 sample code.$

The committer line should not have the extra <> after the (presumably correct) email address, before the two numeric values. (The commit message also does not end with a newline, as you can see by the prompt showing up on the same line, but that's not something git fsck will object to.)

... In any case, in order to fix this, the first thing I have tried is to rebase.

Do not use rebase here! (You could theoretically use git rebase --rebase-merges but that's still the wrong way to go.)

To replace a bad commit like this, use git replace --edit followed by either git filter-branch (obsolete now) or git filter-repo (the new better way, but still not part of Git distributions). But:

... but given the impact rebase can have on a repo, it is not clear I have any of this right. I know if such a change goes through everyone will have to re-clone

That's true however you go about making this change. The reason is that the hash ID of a commit is the commit; making any change to any part, including removing the bogus <> on the committer line, results in a new and different commit with a new and different unique hash ID. All subsequent commits in the repository must refer back to the new commit, directly (for its children) or indirectly (for its grandnchildren, n ≥ 1).

Your best bet, if other constraints allow it, is simply to ignore the problem. Git itself doesn't have any issues reading and using this commit and its files. It just fails to meet the formal requirements (so some other non-Git software that reads Git data might object to it, since accepting it is an extension). That's why git fsck gripes about it. You can disable this particular error message for an entire clone:

git config fsck.badEmail ignore

or for certain known bad commits by hash ID. Whether (and how) you can get GitHub or Bitbucket to do this for you, I'm not sure. See, e.g., https://github.blog/2015-09-29-git-2-6-including-flexible-fsck-and-improved-status/ (which mentions the fsck.badEmail setting, and also the skip-list trick, but not a way to set that up on GitHub itself, and of course you're trying to do this on Bitbucket).

Of course, I was able to clone the entire repository from Bitbucket just now to find this out, so it seems that it's safely there.

user_12564520
Related