You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since we are actually starting with the merge conflict resolution in our
directory and creating the conflicting versions manually, we should be able
to record what the resolution is, detect it and apply the recorded resolution
automatically.
The problem as I understand it is that it's easy to separate a diff into two the way github desktop does it, but putting them back together doesn't work.. But what if we only needed to store and cascade the original line number when splitting diffs to make them addable again?
As an example, if we split this:
@@ -1,4 +1,7 @@
a
b
+c+d+e
f
g
into these two:
@@ -1,4 +1,5 @@
a
b
+d // original line 4
f
g
@@ -1,4 +1,6 @@
a
b
+c // original line 3+e // original line 5
f
g
Then we have enough information to reverse the split? It works even if we split the second diff into two again.
Note: One issue at this stage would be if we paste some function up higher and it
shifts all the lines and then we run the status call again, will we match the
hunk ranges properly? I don't really know enough about exactly how we handle
this scenario now, but if it's difficult, we could keep a cache of what "splits"
we have by content and try to match based on that. But let's tackle this later,
it should be doable one way or another.
Also, about matching up the hunk ranges properly. I don't think we do a good enough job right now, but with a bit of effort we could have something quite solid that matches based on both line range intersection as well as the similarity score @Qix- coded up a while back.
The text was updated successfully, but these errors were encountered:
writeups/230901-sc-vb-sub-hunks.md
Lines 86 to 89 in 6261a22
The problem as I understand it is that it's easy to separate a diff into two the way github desktop does it, but putting them back together doesn't work.. But what if we only needed to store and cascade the original line number when splitting diffs to make them addable again?
As an example, if we split this:
into these two:
Then we have enough information to reverse the split? It works even if we split the second diff into two again.
writeups/230901-sc-vb-sub-hunks.md
Lines 212 to 217 in 6261a22
Also, about matching up the hunk ranges properly. I don't think we do a good enough job right now, but with a bit of effort we could have something quite solid that matches based on both line range intersection as well as the similarity score @Qix- coded up a while back.
The text was updated successfully, but these errors were encountered: