Bjarmason’s post[1] (the parent/replied-to of this submission) explains
a way to both use git-rebase and git-merge in the case when you both
want the rebased history as well as the “previous version” (so to speak
history).
He uses an example similar to this (modified by me):
A---B---C topic
/
D---E---F---G master
What if you want to keep `A - B - C`? But also rebase those commits on
top of master?
The trick here (I think) is to checkout `master`, `git merge -s ours
topic` (which keeps only changes from `master`), and then rebase `A -
B - C` on top of the new merge commit.
Let’s say that `H` is the new merge commit. It will be the case that
`G{tree}` = `H{tree}`, because the merge commit discarded all changes
from `A - B - C`. So rebasing on top of `H` is the same as rebasing on
top of `G`!
Here, the operator rebased and squashed `A` and `B`.
Schindelin (one of the Git For Windows maintainers) responds[2] and says
that he has been using this strategy for years in order to keep up with
Git.
He calls the strategy “merging-rebase”.
In 2021, Schindelin replied to[3] Bjarmason on the same topic:
> Hi Ævar,
>> On Thu, 9 Dec 2021, Ævar Arnfjörð Bjarmason wrote:
>> The difference between "master" and "git-for-windows/main" is large enough that comparing the two will segfault on my system. This is because the range-diff code does some expensive calculations and will overflow the "int" type.
> You are holding this thing wrong.
> The `main` branch of Git for Windows uses merging rebases, therefore you need to use a commit range like `git-for-windows/main^{/^Start.the.merging}..git-for-windows/main` and compare it to `git-for-windows/main..master`.
> Failing that, you will receive only bogus results.
1 comment
[ 3.1 ms ] story [ 10.2 ms ] threadHe uses an example similar to this (modified by me):
What if you want to keep `A - B - C`? But also rebase those commits on top of master?The trick here (I think) is to checkout `master`, `git merge -s ours topic` (which keeps only changes from `master`), and then rebase `A - B - C` on top of the new merge commit.
Let’s say that `H` is the new merge commit. It will be the case that `G{tree}` = `H{tree}`, because the merge commit discarded all changes from `A - B - C`. So rebasing on top of `H` is the same as rebasing on top of `G`!
Here, the operator rebased and squashed `A` and `B`.Schindelin (one of the Git For Windows maintainers) responds[2] and says that he has been using this strategy for years in order to keep up with Git.
He calls the strategy “merging-rebase”.
In 2021, Schindelin replied to[3] Bjarmason on the same topic:
> Hi Ævar,
>> On Thu, 9 Dec 2021, Ævar Arnfjörð Bjarmason wrote:
>> The difference between "master" and "git-for-windows/main" is large enough that comparing the two will segfault on my system. This is because the range-diff code does some expensive calculations and will overflow the "int" type.
> You are holding this thing wrong.
> The `main` branch of Git for Windows uses merging rebases, therefore you need to use a commit range like `git-for-windows/main^{/^Start.the.merging}..git-for-windows/main` and compare it to `git-for-windows/main..master`.
> Failing that, you will receive only bogus results.
[1] https://lore.kernel.org/git/877etds220.fsf@evledraar.gmail.c...
[2] This submission
[3] https://lore.kernel.org/git/nycvar.QRO.7.76.6.2112101528200....