wip changes against more than one parent #1753
Conversation
Before this commit, blame would have been passed to the first parent in
cases where there was more than one.
This commit changes that by only removing a particular suspect from
further consideration once it has been compared to all of its parents.
For hunks where blame cannot be passed to any parent, we can safely
assume that they were introduced by a particular suspect, so we remove
those hunks from `hunks_to_blame` and create a `BlameEntry` out of them.
We can illustrate the change using the following small example history:
```text
---1----2
\ \
3----4---
```
Let’s now say that we’re blaming a file that has the following content:
```text
line 1 # introduced by (1), then changed by (3)
line 2 # introduced by (1)
line 3 # introduced by (1), then changed by (2)
```
The resulting blame should look like this:
```text
(3) line 1
(1) line 2
(2) line 3
```
The previous version of the algorithm would have passed blame to just
(2) or (3), depending on which one came first in the list of parents.
|
Thanks a lot for the refactor! Again, I’ve learned one or two things from it! |
|
Something seems to be wrong with the checks here: there are none. I don't know why. Maybe it is a bug in GitHub triggered by some combination of force pushes? In any case, it looks like the intent here is to merge this once tests pass, but auto-merge is unable to proceed because it is waiting on checks that are not running, nor queued, nor even enumerated. |
|
That is very strange indeed! Instead of trying to fix it by maybe redoing the push after a trivial change, I thought it was easiest to just force-merge with admin overrides. |
|
On main since the merge, it looks like there's a readily fixable clippy error, but otherwise everything is okay. |
|
So close :D, here is the fix gitbutlerapp/gitbutler#5910. |
|
The link goes to gitbutler, but |
|
I think #1754 had the fix. |
The PR #1751 as it should have been.