Johannes Sixt <j6t@xxxxxxxx> writes:
> That question on Stackoverflow asks "how to do X with Y". But Y (git
> cherry-pick) is the wrong tool to do X (apply commits from a branch to
> somewhere else in squashed form).
>
> git diff A...B | git apply --3way
>
> would do what you want. You would have to come up with a new commit
> message anyway, so cherry-pick would be of little use there.
I do agree that cherry-pick is not the best solution for that XY
problem, but in a typical undisciplined development work, it is not
entirely implausible that pieces from original commit message may
still be of some use, exactly the same way as people would want to
use "squash" while "rebase -i". Most commits may have completely
unusable "oops fix", "worked more", etc. messages, but some of them
may summarize what the past handful steps with such garbage messages
have done, which may be worth salvaging.
If I were solving the XY problem, I would probably use "rebase -i".
To transplant the range A..B of the history on top of HEAD, for
example, I'd start with (notice ^0 after B, as I do not trust myself
so I'd leave the true branch B untouched as I may make mistakes
while running rebase):
$ git checkout --detach HEAD ;# this is only to use @{-1} later
$ git rebase -i --onto HEAD A B^0
Then if my goal is to squash everything down into a single commit,
then replace all 'pick', except for the first one, to 'squash'.
That will give me one single chance to edit a single commit message,
but the editor buffer starts with the log message from all of the
original, so I can pick good bits from them while writing new stuf.
I'll have the result on detached HEAD. If I like the result, I may
update the branch I was originally on with it.
$ git checkout -B @{-1}
Or, if I don't, perhaps because I made mistakes, then I can just
discard it and go back to the original branch.
$ git checkout @{-1}
