0

I have a repository where I commit once a week every Thursday.
Today, after committing, when looking at the log, I noticed that I had made a commit on Wednesday last week.
But those changes should have been committed on Thursday last week!
It seems I accidentally ran a commit back on that Wednesday, that I thought I had aborted.

I tried git rebase -i, but it only lets me squash the newer Thursday commit into the older Wednesday one, resulting in one commit on Wednesday. I want the reverse! fixup -c looks like it might do what I want, but it may not, and then I would not know how to recover.
Reordering commits (as suggested in an answer to a similar question) also doesn’t seem to fit the bill, as I want the newer commit description and time stamp, and discard the old one.

So: How do it get there to be only the Thursday commit for last week, with the Wednesday commit changes being part of it. as if it never happened?

Evi1M4chine
  • 6,992
  • 1
  • 24
  • 18
  • 1
    If you can provide us with a [mcve] -- e.g., an example repository and a clear demonstration of your desired end state -- we can probably provide a better answer. – larsks Jul 27 '23 at 17:28
  • @larks: What can’t you reproduce? It’s trivial: 1. use any existing git repository. 2. change something. 3. commit. 4. change something else. 5. commit again. 6. Now try to make the first commit “vanish” but the first changes be part of the second commit instead. – Evi1M4chine Aug 02 '23 at 13:41

1 Answers1

1

During the interactive rebase both swap the lines and squash the now lower commit by changing pick to s. You will be asked for new commit message with both original ones presented.

You can create new branch to experiment with your changes first.

Roman Pavelka
  • 3,736
  • 2
  • 11
  • 28
  • Unfortunately, your answer didn’t state the answer to very thing I asked this for: Will the original commit *date* be the date of the later commit too? Or the date of when I did the rebase / squashing? – Evi1M4chine Aug 02 '23 at 13:44
  • I thought a new branch would be after those old commits, so rebasing things would still mess up the old commits. I can’t even imagine what a mess it would create if it wasn’t. (A branch starting after the commits, that retroactively rebases old commits from before the branching, but keeps those changes in its own later-created branch? Could that even be displayed in gitk without non-euclidean geometry? ;) … And branching before them would mean having to transfer those commits over, where obviously changing the order is trivial. But then I have a branch I don’t want. – Evi1M4chine Aug 02 '23 at 13:49