yaoyuannnn / gerritlab Goto Github PK

Hello! I saw this linked in a stacking MR article the other day and wanted to give it a try but I've been running into issues with the version (15.5.9-ee) of GitLab my company uses internally.

trying to run git lab to update an MR gave me this error

Traceback (most recent call last):
  File "/Users/nicholasdo/Library/Python/3.9/bin/git-lab", line 8, in <module>
    sys.exit(main())
  File "/Users/nicholasdo/Library/Python/3.9/lib/python/site-packages/gerritlab/main.py", line 361, in main
    create_merge_requests(repo, remote, final_branch)
  File "/Users/nicholasdo/Library/Python/3.9/lib/python/site-packages/gerritlab/main.py", line 266, in create_merge_requests
    c.mr.wait_until_stable(c)
  File "/Users/nicholasdo/Library/Python/3.9/lib/python/site-packages/gerritlab/merge_request.py", line 249, in wait_until_stable
    if self._prepared_at and self._sha == commit.commit.hexsha:
AttributeError: 'MergeRequest' object has no attribute '_prepared_at'

I don't think the prepared_at property exists in the version of GitLab we're using 😿

Would be nice to support git lab -d {MR or URL}, as an equivalent to git review -d {changeId or URL}

Please consider renaming git-review to git-lab. Reasons:

1. To avoid a collision with the standard git-revew plugin, especially in the case where people need to deal with both Gerrit and GitLab (such as during Wikimedia Foundation's transition from Gerrit to GitLab).
2. Running git lab would be cool.

Steps to reproduce:

• glab mr checkout 98 (https://gitlab.wikimedia.org/repos/mediawiki/services/ipoid/-/merge_requests/98)
• Make a change, git commit, rebase interactive and update the commit associated with MR 96 (https://gitlab.wikimedia.org/repos/mediawiki/services/ipoid/-/merge_requests/96)
• git lab

Expected:

• MRs 97 and 98 are unchanged, MR 96 has an updated commit message and MR description

Actual:

• New MRs are opened for all three commits.

Right now 4 characters of the Change-Id are used, leaving the very real possibility of a collision in the source branch names of two different commits. I propose increasing to at least 8 characters, maybe even more. Using the whole Change-Id would provide collision resistance on par with Gerrit.

When I run git lab, the script shows me which commits it will operate on:

➜ git lab
Commits to be reviewed:
* 74341cc4 tests: Improve split between test/coverage commands

Proceed? ([y]/n) y

And after it finishes, it shows:

SUCCESS

Updated MRs:
* https://gitlab.wikimedia.org/repos/mediawiki/services/ipoid/-/merge_requests/113 tests: Improve split between test/coverage commands

What I would instead like to see is:

➜ git lab
Commits to be reviewed:
* 74341cc4 tests: Improve split between test/coverage commands -> UPDATE https://gitlab.wikimedia.org/repos/mediawiki/services/ipoid/-/merge_requests/113

Proceed? ([y]/n) y

Maybe a table output would work, with expected statuses (CREATE/UPDATE) and links to existing MRs, if found.

That would help avoid surprises like in #49

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.

To simplify the code and reduce API calls, I propose relying on the behavior of the Auto-cancel redundant pipelines CI/CD setting instead of using cancel_prev_pipelines().

Right now gerritlab pushes commits to branches named after the local branch (or a name supplied on the command line). I suggest a new scheme for naming branches:

<final-target-branch-name>-<fullchangeid>

final-target-branch-name comes from target_branch in .gitreview, unless an override is supplied on the command line.

Advantages:

• The remote branch names never depend on the developer's local branch name. This means you can rename your local branch without worrying about a new set of MRs being created.
• Using the full Change-Id deals with #39

Following up from #31, it would be neat to have the merge request description kept in sync with the commit message contents. (Maybe the "Related MRs" part could go below the commit message.)

That would feel more Gerrit-like and intuitive, IMO.

Then one could use gerritlab to develop gerritlab.

Every cool project should have a cool logo to go with it.

Hi. As the project matures, please consider tagging releases and publishing them to PyPI.

I'm trying to create a MR with gerritlab. I have configured the target branch to be main. I get this error when I run git lab:

Traceback (most recent call last):
  File "/Users/kostajh/src/gerritlab/venv/bin/git-lab", line 8, in <module>
    sys.exit(main())
  File "/Users/kostajh/src/gerritlab/venv/lib/python3.9/site-packages/gerritlab/main.py", line 337, in main
    create_merge_requests(repo, remote, local_branch)
  File "/Users/kostajh/src/gerritlab/venv/lib/python3.9/site-packages/gerritlab/main.py", line 139, in create_merge_requests
    commits = list(
  File "/Users/kostajh/src/gerritlab/venv/lib/python3.9/site-packages/git/objects/commit.py", line 482, in _iter_from_process_or_stream
    finalize_process(proc_or_stream)
  File "/Users/kostajh/src/gerritlab/venv/lib/python3.9/site-packages/git/util.py", line 437, in finalize_process
    proc.wait(**kwargs)
  File "/Users/kostajh/src/gerritlab/venv/lib/python3.9/site-packages/git/cmd.py", line 602, in wait
    raise GitCommandError(remove_password_if_present(self.args), status, errstr)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(128)
  cmdline: git rev-list origin/main..gerritlab --
  stderr: 'fatal: bad revision 'origin/main..gerritlab'

And indeed, git rev-list origin/main..gerritlab -- returns:fatal: bad revision 'origin/main..gerritlab' while git rev-list main..gerritlab returns bd6e6841775e04432bb3539f9f8daa870f0398ad

Not sure what I am doing wrong. Suggestions welcome :)