git squash and keep the last commit exactly

Question

I am getting merge conflicts when squashing commits and the last commit ends up DIFFERENT than it was before the squash. Why does the final result change when i run

git rebase -i someothercommit

then squash undesired intermediate commits leaving only the first?? I don't understand how there can be merge conflicts considering each commit is in series. Some more details are below:

For my workflow I have several branches master 0somefeature 1anotherfeature 2lastfeature

generally 0feature is based off master, 1 is based off 0 etc. when i make a change to master I merge master into 0feature, then 0feature into 1newfeature etc.

this is what i have run:

$ git log --online -5
990cfb1 combine dump, add prog, combine validate
41013a9 Merge branch '5flash_addr' into 6flash_bankcheck
6f5e8f1 nothing interesting
7b8140d nothing interesting
2347714 implementation of dump and program

$ git rebase -i 2347714

then i squash all commits except for 990cfb1, end up with merge conflicts and my new commit is now different than it was before the merge!!

Thanks!

Answer 1

The word "delete" is not correct in your claim "then i delete all commits except for 990cfb1". You need to use squash.

When you run $ git rebase -i 2347714, you'll see text editor pops up showing your all of the messages like this:

pick 990cfb1 combine dump, add prog, combine validate
pick 41013a9 Merge branch '5flash_addr' into 6flash_bankcheck
pick 6f5e8f1 nothing interesting
pick 7b8140d nothing interesting
pick 2347714 implementation of dump and program

At this moment, I'd say DO NOT TOUCH the first one!(990cfb1). Then, for the remaining, replace "pick" with "squash" or "s" as the alias.

Now, save the file and exit editor.

Then, git rebase will continue running. After seconds, another text editor window will pop up showing you all of the commit messages.

At this moment, you are safe to delete all message and rewrite them to one sentence as the final commit message.

Now, save and leave. Git will do the following automatically. Done!

Side note

You may have problem following the above process because your "rebase" has already run but halt for some error.

You need to:

1. Make a physical copy of whole git project to somewhere else at first!!!
2. Then, run git rebase --abort
3. Start from clean state as per the process above.

Answer 2

I've now gotten much better at doing this.. the main problem was the merge of an 'older' branch into the new one, which I was doing multiple times, then rebasing across the merge steps and squashing all the commits. There must be an issue with the hash changing or the commits being squashed out of order.

A better practice would have been to rebase the new branch onto the additional commit on the older branch so the commit history is linear (rather than merging H into G).

             0feature    1feature
                |           |
                v           |
A --  B -- C -- D -- H      |
                 \          v
                  E -- F -- G

In other words, with the above schematic if I make an additional commit H onto D (which will move the 0feature pointer to H), then merge 0feature into 1feature (and do this multiple times), then try to rebase / sqash the entire history between 0feature & 1feature I would end up with problems. Instead of git checkout G; git merge H I should have been using git rebase --onto H D G for each of the little cleanups. I have been doing the second of these options since the original post and have been fine since then.

Also, if this was my commit log:

990cfb1 combine dump, add prog, combine validate
41013a9 Merge branch '5flash_addr' into 6flash_bankcheck
6f5e8f1 nothing interesting
7b8140d nothing interesting
2347714 implementation of dump and program

and I rebase off of 2347714, the rebase option should look like:

pick 7b8140d nothing interesting
s 6f5e8f1 nothing interesting
s 41013a9 Merge branch '5flash_addr' into 6flash_bankcheck
s 990cfb1 combine dump, add prog, combine validate