-
Notifications
You must be signed in to change notification settings - Fork 10
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
Allow multiple commits in a merge request #16
Labels
enhancement
New feature or request
Comments
yaoyuannnn
changed the title
Allow multiple commits in an merge request
Allow multiple commits in a merge request
Aug 18, 2023
dancysoft
pushed a commit
that referenced
this issue
Aug 29, 2023
By stabililze we mean that the "changes_count" field of the MR has a value of "1". This ensures that by the time the "git lab" command terminates, MRs should be fully up-to-date. Note that this approach will have to be reevaluated if #16 is implemented (which would allow multiple commits to end up in a single MR). Change-Id: Id20d9feb27076afe0603bee334badc815e5528a9
dancysoft
pushed a commit
that referenced
this issue
Aug 30, 2023
By stabililze we mean that the "changes_count" field of the MR has a value of "1". This ensures that by the time the "git lab" command terminates, MRs should be fully up-to-date. Note that this approach will have to be reevaluated if #16 is implemented (which would allow multiple commits to end up in a single MR). Also: unit_tests/merge_request_test.py: MergeRequestTest: Removed WAIT_TIME_BEFORE_VALIDATE, etc since create_merge_requests() now waits for the desired state before returning. Change-Id: Id20d9feb27076afe0603bee334badc815e5528a9
dancysoft
pushed a commit
that referenced
this issue
Aug 30, 2023
By stabililze we mean that the "changes_count" field of the MR has a value of "1". This ensures that by the time the "git lab" command terminates, MRs should be fully up-to-date. Note that this approach will have to be reevaluated if #16 is implemented (which would allow multiple commits to end up in a single MR). Also: unit_tests/merge_request_test.py: MergeRequestTest: Removed WAIT_TIME_BEFORE_VALIDATE, etc since create_merge_requests() now waits for the desired state before returning. Change-Id: Id20d9feb27076afe0603bee334badc815e5528a9
Given the hard one-commit-one-MR setup of everything, I don't think this change is going to work out. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As discussed in #11, there are use cases where we would want multiple commits to exist in a merge request, while still maintaining the stacked merge request hierarchy. Initial idea was having a "git lab -i" command to let the user interactively decide how to group the commits (similar to the same flag in git rebase -i). An example is shown below, in which commit 2 and commit 3 will be combined into the same MR as commit 1.
The text was updated successfully, but these errors were encountered: