-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate "fast forward" and empty merges #3274
Comments
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 👋 |
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.
The text was updated successfully, but these errors were encountered: