lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

updating merge request


From: David Zelinsky
Subject: updating merge request
Date: Thu, 19 Jan 2023 23:54:25 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

I made my first merge request the other day.  I have made some changes
in response to review comments, and I want to upload these.  But I'm
confused about instructions in the Contributor's Guide.

My inclination is to commit the changes on my local branch and then push
to the same dev/* branch in my gitlab fork for which I submitted the
merge request.  This is also what seems to be suggested in CG
3.3.3. "Patch countdown":

  "Successive revisions are made in response to comments are uploaded by
   pushing to the same branch. GitLab automatically keeps track of all
   pushed commits and allows to compare revisions with each other."

However, in GC 3.2 "Git cheat sheet", under "Uploading your branch for
review", it says to always amend the existing commit rather than create
a new one:

   "In response to review comments, you may need to amend your
   changes. Do not close your merge request and open a new one; instead,
   amend your commits, which can be done with git commit --amend or git
   rebase -i as explained above. Note that Git will by default refuse a
   push when you have amended your commits. This is because this kind of
   push is a destructive operation: once it is done, the old commits are
   no longer available on the remote branch. Git prevents this as a
   safety measure against deleting commits added by someone else without
   you realizing it. Do not follow Git’s advice to do git pull (which
   would try to integrate the remote changes into the local ones);
   instead, just force it with git push --force-with-lease"

This seems very strange to me, since the merge request is for a
particular branch head, which would get updated with the new commit.  I
would not have to make a new merge request.  Why would I want to clobber
the revision history on the branch to be merged, before it is merged?

Am I misunderstanding something?  Or is what it says in 3.2 a mistake?

-David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]