Skip to content
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

Open
yaoyuannnn opened this issue Aug 18, 2023 · 1 comment
Open

Allow multiple commits in a merge request #16

yaoyuannnn opened this issue Aug 18, 2023 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@yaoyuannnn
Copy link
Owner

yaoyuannnn commented Aug 18, 2023

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.

pick 1568d commit 0.
pick 6bb03 commit 1.
combine 8abc3 commit 2.
combine d4568 commit 3.
pick 89b03 commit 4.

# Review commits using GerritLab.
#
# Commands:
# p, pick <commit> = use commit for an individual MR.
# c, combine <commit> = combine commit to be in the same MR as the previous commit.
@yaoyuannnn yaoyuannnn changed the title Allow multiple commits in an merge request Allow multiple commits in a merge request Aug 18, 2023
@yaoyuannnn yaoyuannnn self-assigned this Aug 18, 2023
@yaoyuannnn yaoyuannnn added the enhancement New feature or request label 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
@dancysoft
Copy link
Collaborator

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
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants