Open arielshaqed opened 2 years ago
this seems a bit more complex than what I've taken up so far but I am willing to give it a try! Assign it to me please :)
makes sense!
With pleasure. @johnmantios here's some material for ramping up on lakeFS internals:
This issue is now marked as stale after 90 days of inactivity, and will be closed soon. To keep it, mark it with the "no stale" label.
@johnmantios please let me know if you still want this issue, of course!
Hey @arielshaqed 👋 Unfortunately I cannot take this: my current job takes almost all of my time 😔
This case is currently mishandled, even after #3270.
Say we develop the exact same 5 files on two branches, but with different orderings:
Here, branch
develop
first added a,b,c, and then d,e, while branchmain
first added a,c,e, and then b,d. These are the exact same files, so there is no new metarange to write in the merge: either both branches ended up with the same ranges structures and therefore share a metarange ID, or the ranges structures are different and the merge can pick either one or create a third metarange ID.But it is a new commit! This merge commit says that main and develop were the same, but it has different parents than both last commit IDs (
+d,e
ondevelop
,+b,d
onmain
). It's not even a fast-forward merge.Current code (correctly!) identifies that no new metarange ID is needed, but then (incorrectly!) fails with an error and prevents the new merge commit from being created.