10

Maybe I misunderstood how GIT works.

I've run git rebase -i HEAD~10 and I could squash 10 commits into one. The issue is that all squashed commits are still there, and I thought they were going to be dropped after merging them all into one.

Is this the expected result? If so, can I rewrite the history to remove useless commits (since these changes are already in the commit which all previous commits were squashed)?

Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206

3 Answers3

7

When you began your interactive rebase session, you should have been prompted with a list of the last 10 commits from the current branch:

git rebase -i HEAD~10

pick as2i8dw first commit
pick ee361eb second  commit
...
pick b2762sx most recent commit

You need to change this file to the following:

pick as2i8dw first commit
squash ee361eb second commit
...
squash b2762sx most recent commit

Then you need to do a git commit to save the changes. Now when doing a git log you should only see the as2i8dw commit and none of the other ten.

That being said, is this what you did?

CherryDT
  • 25,571
  • 5
  • 49
  • 74
Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • Yes! I did this excepting the `git commit` thing. I've done `:qw` in VIM CLI and it done the rebase with no issues (excepting the unexpected result) – Matías Fidemraizer Jul 26 '15 at 11:21
  • So are you squared away or is there still a problem? – Tim Biegeleisen Jul 26 '15 at 11:29
  • Still. I'm thinking if it would be easier if I create a new branch, and I put my changes there manually, and I publish the branch. Things are getting complicated. – Matías Fidemraizer Jul 26 '15 at 11:46
  • If you have this branch in a remote repo, you could do as you said and just create a new local branch from it. If your branch really is _identical_ to what it was before the bad rebase, then maybe nothing happened other than a new commit. Nuke this commit and try again. – Tim Biegeleisen Jul 26 '15 at 13:02
  • 1
    I did this (the thing of nuking commits) and I've rolled back to the previous state before trying the squashing thing. I'll try to rebase again and let's see what happens – Matías Fidemraizer Jul 26 '15 at 20:46
4

The issue is that all squashed commits are still there

If those commits are still accessible by any other reference (other branch or tag), there would still be visible, even after the current branch is rebased.

Try instead squashing the commits with a git reset --soft.
If HEAD does still reference your 10 commits:

git reset --soft HEAD~10
git commit -m "squashed 10 commits"
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • The whole commits are mine and they're still not merged – Matías Fidemraizer Jul 26 '15 at 11:01
  • We need to figure out what went wrong before we suggest a fix. – Tim Biegeleisen Jul 26 '15 at 11:04
  • It depends then how you did the squashing. Try again, this time with a git reset (I have edited my answer) – VonC Jul 26 '15 at 11:04
  • Check the repo commit history: https://github.com/mfidemraizer/StackExchange.Redis/commits/master . "whatever" commit is what I got after squashing using a `git reset`. BTW, my previous commits are still there :\ – Matías Fidemraizer Jul 26 '15 at 11:42
  • I tried again, see the commit with "squashed" message: https://github.com/mfidemraizer/StackExchange.Redis/commits/master – Matías Fidemraizer Jul 26 '15 at 12:06
  • Sadly, previous commits are still there. I did a `git reset --soft 83a046eb` and later the so-called `git commit -m "squashed"` – Matías Fidemraizer Jul 26 '15 at 12:08
  • @MatíasFidemraizer That is strange. I can only think about something else referencing those commits to explain why there would still be there. – VonC Jul 26 '15 at 12:09
  • Does the squashed commit, that is removed from the history, still remain in the github repo? – alper Apr 12 '22 at 12:04
  • 2
    @alper They won't, once you have `git push --force` your local branch, to override the history of the remote branch on GitHub. If they are still visible (after the force push), that would be (as mentioned in the answer) because something else (another branch or tag) references the old commits. – VonC Apr 12 '22 at 15:43
  • @VonC Thanks I e-mailed GitHub to run garbage collector but I am not sure it will clean the history. I am using `git squash` a lot (like after a making single line change I squash my changes) overall it becames over hundred squashed commits per day. Seems like its not a good approach since it will leave foot-print in the GitHub. – alper Apr 12 '22 at 17:26
1

I faced the similar issue and figured out the actual cause for it: The flow:

git rebase -i HEAD~10
# Retain the first commit from below( as pick) and change the rest of the `pick` to `squash`
# After your rebase is successful
git log
# You can see all your commits squashes to one commit

Then now when you git pull from your remote branch, it will pull the rest of the commits which is not there in local ( basically all the commits you had squashed previously, since it is now present in one commit) and hence you are seeing the previous commits as well.

Better way is to git push -f to your remote branch, if you are confident that you have no new changes added there.

P.S: If you have any new changes in the remote branch, better to:

git rebase origin remote_branch

and then squash your commits.

Anusha Rao
  • 11
  • 3