0

I want to squash commits in git after they have been pushed. So I find the question How to squash commits in git after they have been pushed?.

I do as the accepted answer said:

git rebase -i origin/master~4 master

But I forget to add the + parameter before the master while pushing it to github. It means I use git push origin master rather than git push origin +master.

I want to know does it matter much and how to undo that so I can use the right command.

-------------------EDIT1----------------------------

I use emacs magit as my git client, so specificly speaking, I use magit-push-other origin master.

Magit's log is below, the red rectangle circles two commits I want to squash. After I squash that two commits, magit informs me that there are one commit unpushed and two commits unmerged from upstream. Then I use magit-pull-from-upstream and magit-push-other origin master to complete those changes. Then the commit log is what the picture draws.

magit-log

If git push origin master wouldn't work at this situation, it seems it's more like a magit question.

Ynjxsjmh
  • 28,441
  • 6
  • 34
  • 52
  • 1
    Are they successful pushed then? If you could push without force, than that's even better. – Julian Jun 22 '19 at 13:20
  • @Julian Yes, the three same commit messages on my github [commit history](https://github.com/Ynjxsjmh/AwesomeArticle/commits/master) indicate that. – Ynjxsjmh Jun 22 '19 at 13:25
  • If `git push origin master` worked, then you didn't need the `+`. `+master` says force push the `master` branch, which means to push even if your master is not a fast-forward of master on the remote server. Given your question, I'm surprised it worked, though: had you really pushed the commits you squashed, or where they just on your local `master` branch? – joanis Jun 22 '19 at 15:21
  • @joanis Thanks for your reply, I think they are both on my local and origin master brach. And I edit my question and add more detail about the process. – Ynjxsjmh Jun 23 '19 at 01:11
  • @rkta Sorry for replying so late, because I didn't get what you said days ago. But now I seem to understand what you said. Do you mean: after squahing multi commits, there should be changes unmerged. At this time, we shouldn't pull from upstream, instead we should do a force push. Then the unmerged changes should auto gone. – Ynjxsjmh Jul 01 '19 at 05:51
  • See my answer, hope this clarifies things. – rkta Jul 02 '19 at 12:03

2 Answers2

3

What to do if you forget the + parameter

The + means to do a force push. If you forget it in a case where it is needed, you'll get an error message. Solution then is to do it again with +.

But you should really learn more about rewriting history in git before using techniques like that.

Rule of thumb: Don't rewrite history after you pushed -- this means you probably never need to force push.

Why didn't you get an error and why was the result not as expected?

Problem is, that you did a pull after the squash.

Why is git showing that there is one commit unpushed and two commits unmerged from upstream?

You created two commits A and B and pushed those to origin. Now, when you squash those commits locally both get deleted and replaced by a new commit C.

Then git sees two commits (A and B) on origin which are not in your history -- of course, you just deleted them. If you do a git pull, your just deleted commits and the newly created one are merged together.

Solution 1:

Don't rewrite history once it got pushed!

Solution 2:

Don't pull after squashing commits, just force push. Really don't do this with shared branches!

rkta
  • 3,959
  • 7
  • 25
  • 37
2

As @rkta pointed out, the problem was created when you did a pull after squashing: you'll notice that your Git log now has three commits to edit your grammatical errors: the original two, plus the squashed one, merged together into c6f979b. That merge commit was created by git pull.

At this point, I recommend you not try to fix this problem, as your collaborators have probably fetched your changes and they will have to do some work to fix their sandboxes if you try to fix this history again. In general, from the moment you push a commit, I would say you should let the history stand even if you don't like it - force pushing only makes more work for others.

That being said, here's how you could still fix it, and how you could have fixed it in the first place:

git pull
git rebase -i a8ba675
# mark the grammatical error commits to be squashed -
# this will still work even though you already merged
git fetch
# use git log --all to make sure no one committed anything since the pull above
git push origin +master
# pray no one comes to yell at you
joanis
  • 10,635
  • 14
  • 30
  • 40