Hi Bulat, Please make sure to keep the Git mailing list in Cc: (I get *very* prickly when Git users treat me as a free-of-cost help desk, and when I get that annoyed, I stop helping). On Tue, 6 Feb 2018, Bulat Musin wrote: > Yes, I tested again. > > With built 2.16... and it shows error message. git rebase --abort restores > > state before rebase. You misunderstood me. I am convinced that that error message *is correct*. It shows an incorrect usage. You cannot start off an interactive rebase by a `squash` command. > With git 2.14 from Ubuntu's repo it works - 3 commits are squashed into first > one Yes, but you called `git rebase -i HEAD~2`, which means that only two commits were up for rebasing. The third commit is outside the range `HEAD~2..` which the command `git rebase -i HEAD~2` wants to let you rebase. If v2.14 indeed modified `HEAD~2` (as I suspected in my earlier mail), then you successfully confirmed that we fixed a bug, and that you expected the buggy behavior. > - with change SHA. > > It seems to be bug in recent version. > > Should I provide additional information? Ciao, Johannes > On 02/06/2018 12:47 PM, Johannes Schindelin wrote: > > Hi, > > > > On Mon, 5 Feb 2018, Bulat Musin wrote: > > > > > Now there are 3 sequential commits, I want to squash them into 1: > > > > > > git rebase -i HEAD~2 > > > > > > In editor I changed all "pick" to "squash", saved file, I got: > > > > > > error: cannot 'squash' without a previous commit > > You cannot start with a squash. You have to pick the first one, then > > squash the second into the first. > > > > > However, 2.14.1 from Ubuntu's repo does the job - squashes 3 commits into > > > 1. > > It may be careless enough to do that, however, it might now have modified > > the *wrong* commit, i.e. squashed the two patches *into HEAD~2*. > > > > Please verify that your HEAD~2 is still intact and part of the rebased > > history, otherwise you will have a problem. > > > > Ciao, > > Johannes > >
