Re: Possible issue with rebase's --rebase-merges option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Joel

On 21/07/2020 22:20, Joel Marshall wrote:
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
This is a difficult one to give proper steps to reproduce. The issue
is with rebase's --rebase-merges flag. We recently switched from using
rebase with the --preserve-merges option to --rebase-merges. Most of
the time the output is the same, but sometimes it is very different.
I'm unable to determine whether this is by design or a bug.

--preserve-merges is buggy if you rearrange the commits (this is way --rebase-merges was added), if you're just rebasing without reordering anything then I think the result should be the same though there may be some corner cases I'm not aware of. Are you able to share the topology before rebasing and after with --preserve-merges and --rebase-merges?

What did you expect to happen? (Expected behavior)
Resulting graph after running rebase --rebase-merges is the same as
running rebase --preserve-merges.

What happened instead? (Actual behavior)
Using --rebase merges tries to pick substantially more commits and
results in merge commits with no parent commit when viewing log in
reverse chronological order.

What's different between what you expected and what actually happened?
When the issue does occur (it doesn't for all rebases) it results in
two completely different logs and picks commits that are apparently
not part of the branch being rebased. eg, for a branch with 128
commits including merges, --preserve-merges picks 128 commits and the
resulting topology matches the original branch's topology.
--rebase-merges picked 183(?) commits in v2.24 and 202 commits in
v2.27, and in both cases resulted in a very strange topology.

That's interesting there were some changes to how empty commits and upstreamed commits are handled between v2.24 and v2.17, without seeing the staring point and the results it's hard to tell what is going on though.

Without seeing some examples it's hard to tell if there is a bug here or not though it does sound a bit suspicious.

Anything else you want to add:
Feel free to contact me at joel@xxxxxxxxxxxx for additional details.

You email me directly if there are things you don't want to share on the list

Best wishes

Phillip

I
would love to understand if this is by design or a legitimate bug.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.27.0.windows.1
cpu: x86_64
built from commit: 907ab1011dce9112700498e034b974ba60f8b407
sizeof-long: 4
sizeof-size_t: 8
uname: Windows 10.0 18363
compiler info: gnuc: 10.1
libc info: no libc information available


[Enabled Hooks]




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux