3

Suppose I have some commits:

<sha1> bug due to function1
<sha2> bug due to function2
... other commits

and I would like to squash commits 1 and 2 together, keeping only the message of the second commit, then I would use git rebase -i, edit to:

pick <sha1> bug due to function1
squash <sha2> bug due to function2
... other commits

And I would always need to edit the combined messages and delete the first one.

I know I could rearrange the commits and use fixup like this:

pick <sha2> bug due to function2
fixup <sha1> bug due to function1
pick <sha3> other commit

but then I have the risk that, reversing the order of the two commits, there might be some conflicts.

How could I achieve the same result with less manipulations, especially avoiding the editing of the combined message. Note that there might be many commits before commit 1 and after commit 2.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Chris Maes
  • 35,025
  • 12
  • 111
  • 136

3 Answers3

2

First do git log to view the hashes of the last four commits. Reset to the last commit before the two that you want to squash:

git reset --hard <sha0>

...where is the last commit before the two that you want to squash.

Then, try the following commands in order:

git cherry-pick -n <sha1>
git cherry-pick -n <sha2>
git commit
git cherry-pick    <sha3>

The first two commands will combine <sha1> and <sha2> in your local staging sandbox. When you do git commit with no arguments, it will commit the changes using the commit message of the last commit. All you need to do is exit the editor after reviewing the commit message. The final cherry-pick applies the last commit, unchanged.

mkrufky
  • 3,268
  • 2
  • 17
  • 37
  • 1
    multiple problems with this: The commits are already in the branch I'm working on; so this won't work PLUS I need to look in the history to get the two sha,... so much more work than git rebase -i etc... I want a solution that is less work... – Chris Maes Jan 06 '16 at 13:06
  • you'd obviously have to `git reset --hard ` where sha0 is the hash before the two that you want to squash, before proceeding with the cherry picks. This does answer your question, exactly. If you're asking for a way to do it within the interactive mode, only, then it should be reflected in the question. – mkrufky Jan 06 '16 at 13:09
  • agreed that this solution will work if these are the two last commits in the tree. I adapted my question so that it is more clear that I would like a solution if these commits can be somewhere else in my history. Please adapt your answer so that it mentions "solution only if these are the last two commits" or something like that; which is a partial solution ... – Chris Maes Jan 06 '16 at 13:15
  • oh and suggestion for less editing: `git reset --hard HEAD~2` is easier :) – Chris Maes Jan 06 '16 at 13:16
  • I adapted the answer to instead match the new (edited) question – mkrufky Jan 06 '16 at 13:17
  • ok, I agree that your solution will work, so I'll upvote, but it isn't really a practical solution, since it will require much work, especially if there are commits 4, 5, ... – Chris Maes Jan 06 '16 at 13:18
  • I usually avoid using the relative macros (such as HEAD) when helping others use git, as it involves a deeper level of understanding of git that many beginner git users don't yet have. You're right though, `git reset --hard HEAD~2` is a nice shortcut, but actually copy/pasting the hashes from `git log` give the user a sense of certainty that he has picked the exactly correct revision. I am not sure why you are calling this "more work" -- it's just a copy/paste. But everybody has their preferences. That's a great thing about git - it's so flexible, and there are many ways to achieve a result – mkrufky Jan 06 '16 at 13:22
  • my solution: git rebase, edit file to put squash instead of pick, edit combined message = 3 operations. Your solution, suppose your example above: git log to find correct hash, git reset, 2 cherry-picks, git-commit, git cherry-pick = 6 operations... and incremental for more commits – Chris Maes Jan 06 '16 at 13:26
  • Your original question asked how you can avoid manually editing the commit message of the two squashed commits. My solution solved that. :-) – mkrufky Jan 06 '16 at 13:28
  • @mkrufky sorry your solution wasn't appreciated, this is actually quite clever, especially if sha1 and sha2 it's not just the message but other commit metadata you care about. The other points are easily handled with rebase mechanics (eg. instead of hard reset, start a new branch from sha0, do your trick, and then rebase the trailing commits --onto it). – gtd Mar 21 '18 at 05:50
0

A fully automated version. Suppose a git history like this:

... (as many commits as you like)
6acdc6f - commit message 3
46c9468 - commit message 2
9b28fd5 - commit message 1

then rebasing to squash commit 1 and 2 together and keep commit message 2:

git rebase -i 9b28fd5~

and then editing like this:

pick 9b28fd5 commit message 1
pick 46c9468 commit message 2
exec HH=$(git rev-parse HEAD); git reset --soft HEAD~2; git commit -C $HH
pick 6acdc6f commit message 3

a small explanation of the shell commands:

HH=$(git rev-parse HEAD) # store the HEAD sha1 in a variable; since the next call will change HEAD to HEAD~2
git reset --soft HEAD~2  # destroy the last two commits keeping the changes staged.
git commit -C $HH        # now commit all changes reusing the commit message from commit2 (using the sha1 that we saved in the variable)
Chris Maes
  • 35,025
  • 12
  • 111
  • 136
0

Since the OP's question, do note the behavior of an interactive rebase did change (and is now fixed, Q1 2021).

When "git rebase -i"(man) processes fixup insn, there is no reason to clean up the commit log message, but we did the usual stripspace processing.
This has been corrected with Git 2.31 (Q1 2021).

See commit f7d42ce (28 Jan 2021) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 7e94720, 10 Feb 2021)

rebase -i: do leave commit message intact in fixup! chains

Reported-by: Vojtěch Knyttl
Helped-by: Martin Ågren
Signed-off-by: Johannes Schindelin

In 6e98de7 ("sequencer (rebase -i): add support for the 'fixup' and 'squash' commands", 2017-01-02, Git v2.12.0-rc0 -- merge listed in batch #8), this developer introduced a change of behavior by mistake: when encountering a fixup! commit (or multiple fixup! commits) without any squash! commit thrown in, the final git commit(man) was invoked with --cleanup=strip.
Prior to that commit, the commit command had been called without that --cleanup option.

Since we explicitly read the original commit message from a file in that case, there is really no sense in forcing that clean-up.

We actually need to actively suppress that clean-up lest a configured commit.cleanup may interfere with what we want to do: leave the commit message unchanged.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250