0

When I run git fsck I have some bad commits that I need to fix:

$ git fsck
Checking object directories: 100% (256/256), done.
error in commit 60707e738f5b4330147fff34d7ddc734eea4a577: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in commit c60d233e8296f9c7a1f6e50719e59bac6fdd272f: badDate: invalid author/committer line - bad date
Checking objects: 100% (163912/163912), done.

I tried to follow the answer in how-do-i-modify-a-specific-commit but when I run:

git rebase --interactive 'c60d233e8296f9c7a1f6e50719e59bac6fdd272f^'

I don't see c60d23 in the list of commits to edit, so there is nothing for me to "fix", since the commit in question is not on that list.

Any ideas on how I can fix this bad date error on this commit? Any third party tools that may help?

Thanks!

=====Update based on @hlovdal Answer=====

I ran git branch --contains c60d23 but it does not return anything.

I also ran:

git tag fsck-bad-60707e73 60707e73
git tag fsck-bad-c60d233e c60d233e
gitk --all &

And this is what I see: enter image description here

But since that commit does not exist in a branch, I don't know how to rebase it :(

grayaii
  • 2,241
  • 7
  • 31
  • 47
  • Why the quotes around the ref you pass? – Romain Valeri Jan 05 '23 at 15:43
  • 1
    @RomainValeri it's generally a good idea to quote everything. The quotes aren't visible to `git rebase` (they are interpreted by the shell before the command runs). – larsks Jan 05 '23 at 16:11
  • "Generally a good idea" sounds like cargo cult programming to me. If there are identified reasons (at least one) to use them, I'll happily do. But just in case? I find it unsatisfying. – Romain Valeri Jan 05 '23 at 16:25
  • 1
    I'm not sure if ^ is a special character in bash/zsh or whatever $SHELL is set to, so to remove ambiguity, I quoted it, but I can remove quotes from that if it causes confusion. Just a heads up that other links in StackOverflow have quotes around the githash when doing a rebase. – grayaii Jan 05 '23 at 18:06
  • I'm the one who caused the off-topic, sorry for the noise (although I'm glad I learned a bit more on the subject in the process. Let's close the parenthesis here guys.) – Romain Valeri Jan 05 '23 at 21:33

1 Answers1

0

I don't see c60d23 in the list of commits to edit, so there is nothing for me to "fix", since the commit in question is not on that list.

What commits come up in the list with interactive rebase is dependent on which branch which is checked out when you run the interactive command. It is not unthinkable that the commit c60d23 is present on some other branch and not visible from your branch (it could maybe also be a dangling commit).

So start by finding out which branches that contains the commit by running

git branch --all --contains c60d23

Also/alternatively you can look at the commits with gitk

git tag fsck-bad-60707e73 60707e73
git tag fsck-bad-c60d233e c60d233e
gitk --all &

and then press F2 to locate those two commits. From there you should be able to see which branches that contains those problematic commits.

hlovdal
  • 26,565
  • 10
  • 94
  • 165
  • Thank you so much for spending the time looking at this. I updated my question with the results of your commands. In a nutshell, "git branch --contains c60d23" does not return anything and "gitk" I see that commit, but I'm not sure how to rebase it. – grayaii Jan 06 '23 at 03:19
  • The command `git branch --contains c60d23` should be `git branch --all --contains c60d23` to search all branches, not just commits that are visible from the current head. I'll update the answer. – hlovdal Jan 13 '23 at 18:27
  • With regards to rebasing, this can be done with interactive rebase, and with your history you want to to keep the merges, so run with `--rebase-merges` argument. – hlovdal Jan 13 '23 at 18:30