-
Notifications
You must be signed in to change notification settings - Fork 361
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
Add "allow-empty" flag to Merge #7798
Conversation
@itaigilo You've added the parameter in swagger but did not add the logic in lakeFS. |
@N-o-Z this is only a tiny draft, meant to outline the suggested change in the API (before implementing it). |
Thanks, IMHO I think the in this instance it's redundant. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
It's great that you sent this PR out for a round of comments. Please also post a link to it on lakeFS Slack #dev channel: The People Must Know, and they may have opinions...
Only required change is to document what "force" will do once we already have this flag.
api/swagger.yml
Outdated
@@ -645,6 +645,10 @@ components: | |||
force: | |||
type: boolean | |||
default: false | |||
allow_no_changes: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
I guess we will need to document the flag above, too! In particular, what happens if I set
force
but notallow_no_changes
? In order to keep the minor version guarantee, I think that the merge has to fail. This will not be clear to users not aware of the history we are now creating.So I insist on documenting what force does (sorry, it should have been done before), and I think that it should be documented as not allowing an empty merge.
-
I believe that this flag should be called allow_empty. It is already called allow_empty for commit and for revert. I don't want to learn another term, and I don't like boolean flags whose names are negative.
♻️ PR Preview 50540c1 has been successfully destroyed since this PR has been closed. 🤖 By surge-preview |
Message: apiutil.Ptr("Merge branch2 to branch1"), | ||
}) | ||
testutil.MustDo(t, "perform merge with no changes", err) | ||
if mergeResp.JSON400 == nil || !strings.HasSuffix(mergeResp.JSON400.Message, graveler.ErrNoChanges.Error()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a better way to check this error message?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately not for a test at the controller level, this is more of a component test than a unit test. You could unit-test the exact error in TestGravelerMerge (in graveler_v2_test.go, "v2" for Historical Reasons). But I'm not sure it's worth the effort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This is clear and tested code.
Neat that the majority of changed lines are just a cleanup.
Message: apiutil.Ptr("Merge branch2 to branch1"), | ||
}) | ||
testutil.MustDo(t, "perform merge with no changes", err) | ||
if mergeResp.JSON400 == nil || !strings.HasSuffix(mergeResp.JSON400.Message, graveler.ErrNoChanges.Error()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately not for a test at the controller level, this is more of a component test than a unit test. You could unit-test the exact error in TestGravelerMerge (in graveler_v2_test.go, "v2" for Historical Reasons). But I'm not sure it's worth the effort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Blocking for the following questions:
- What is the current behavior when trying to merge a branch with no changes?
- What will be the default behavior after the change?
Noticed it was answered in the updated description |
Closes #7797.
Change Description
Add
allow_no_changes
flag to branch merge API, to allow merge merging two branches with the same content.Background
Currently, when trying to merge two branches with the same content, an "no changes" error is thrown.
New Feature
Add the flag to the API,
And implement support for it in
lakectl
and in thepython-wrapper
(in addition to the auto-generated clients).This change should be fully backwards-compatible.