[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
- updating merge request,
David Zelinsky <=
- Re: updating merge request, Aaron Hill, 2023/01/20
- Re: updating merge request, Werner LEMBERG, 2023/01/20
- Re: updating merge request, Aaron Hill, 2023/01/20
- Re: updating merge request, Jean Abou Samra, 2023/01/20
- Re: updating merge request, Aaron Hill, 2023/01/20
- Re: updating merge request, Luca Fascione, 2023/01/20
- Re: updating merge request, Jean Abou Samra, 2023/01/20
Re: updating merge request, Lukas-Fabian Moser, 2023/01/20