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
