1

I am currently in the situation that some of my newest commits have overwritten the content of an old commit.

I am using the tool git extension, from the GUI interface, I can checkout a certain revision - a commit.

So I checked outed the revision, and can locally see that the files exist - but there doesn't seem to be anything to commit? Which I guess makes sense?

How do I re-push a prior commit?

ascripter
  • 5,665
  • 12
  • 45
  • 68
anita
  • 193
  • 10
  • I would be careful with resetting, as @YesThatIsMyName suggested, since (hard) resets are potentially destructive. Instead, there is a solution for your problem in [this answer](https://stackoverflow.com/a/23683020/7598462): `git show COMMIT_ID | git apply` – kowsky Feb 13 '19 at 09:09
  • What **exactly** do you mean by "overwritten", do you mean that the changes have been reverted, or do you mean that someone removed the commit from the history? – Lasse V. Karlsen Feb 13 '19 at 11:00
  • Do **NOT** use reset until you know the consequences. This command is given as a tip for most odd cases and quite often lead to even more problems than you had before. – Lasse V. Karlsen Feb 13 '19 at 11:01

4 Answers4

1

Say we have a scenario where our previous commit log is like 

git status
commit-1 [ bad commit ]
commit-2 [ bad commit ]
commit-3 [ bad commit ]
commit-4 [ good commit ]
commit-5 [ good commit ]

Two thing now we may want.

first Case

We may want to remove our all bad git commit and will want to go to last good commit stage. Say like following 

git status
commit-4 [ good commit ]
commit-5 [ good commit ]

We can do this by rest first three commit like this 

git reset --hard HEAD~3 
# for n number of last commit reset 
git reset --hard HEAD~n

I must mention this is very hard way to undo your work. Please do it when you are totally sure why you like to do this.

Second case

You may want to put your commit-4 in the top of those

git status
commit-4 [ good commit ]
commit-1 [ bad commit ]
commit-2 [ bad commit ]
commit-3 [ bad commit ]
commit-4 [ good commit ]
commit-5 [ good commit ]

You can do this like following

git cherry-pick -n <commit-4 sha1>

These will put commit-4 top of those bad commit.

Shakil
  • 4,520
  • 3
  • 26
  • 36
0

did you try to cherry-pick the commit on top? git cherry-pick

Chris
  • 200
  • 1
  • 6
0

I suggest one of two ways.

Revert

If your new commit did not contribute anything useful. And it simply un-did what you did in your earlier commit use git-revert. It will create a new commit that un-does whatever the reverted commit did.

In the git command line you identify the bad commit with

git log

keep its ID (example 12345abcd). Then revert that commit

git revert 12345abcd

Cherry-Pick

If your new commits did something good besides breaking your old commits you may cherry pick the old commits you like to have. It will apply the same code changes as the previous commit. However, it will become a new commit. That keeps your branch consistent with older pulls.

First identify the commit you like to apply again with git log and keep the ID (eg fedc9876)

git cherry-pick fedc9876

If you like more control over the cherry pick use the -n flag to prevent immediate commit

git cherry-pick -n fedc9876

You mentioned you use a git tool. The git commands might help you to find how to use it for this purpose.

gschenk
  • 827
  • 9
  • 17
0

So I ended up creating a new branch and moved my files over there, I later had a similar issue where I noticed that the local branch and the remote branch naming wise was not the same.

I had performed a git push -f, as I wanted to rebase with our master, but the local branch name was not the same as the remote one, meaning a remote branch was created and that one contained the new commit.

It seems like that gitExtension by default create local branch with capital start letter - which is not always the case when I create a remote branch.

anita
  • 193
  • 10
  • Please do not `push -f` when you re-based a branch. Rebase is ok if a branch is only local. But as soon as you get a branch from `origin`, rebase it, and force it back again you break the commit history for everyone else. Don't even do it when you use origin alone. You train bad practice and you might break things for yourself if you have more than one clone. Either make new branches, or correct your mistake without changing history. It is often OK when the commits show that you made a mistake and changed it. – gschenk Feb 03 '20 at 21:06