>> Am I misunderstanding something? Or is what it says in 3.2 a
>> mistake?
>
> If GitLab works similar to GitHub
In this case, it does not, or rather, we don't want what is standard
on GitHub.
> any new commits to your branch should automatically be picked up as
> part of the open merge/pull request.
While this is true, the preferred way is to construct the MR anew,
using `gith push -f ...`.
> I think 3.2 might only be advising against creating a *new* branch and
> submitting another request.
Yes.
> But the --amend instruction seems odd as that is usually about
> correcting an incomplete commit, for instance when a file that was
> supposed to be staged was missed.
`--amend` is the way to go. Assume that your MR contains, say, five
commits, and someone has found a typo in the third last commit. You
then have to call `git rebase -i HEAD^^^`, fix the typo, execute `git
add -p` to prepare your change for addition, then `git commit --amend`
to really merge the change with the actual commit (i.e., the commit
that you currently are in the 'rebase' process), and finally `git
rebase --continue` to finish.
> It looks clunky to have a second commit when you can often get away
> with fixing up the original commit to be complete. Otherwise, you
> are basically rewriting history, and that is a general no-no.
As long as you are in a MR, you actually *should* rewrite history.
> One should let all commits sit clearly in the open during review and
> then at the end squash or rebase or whatever before merging based on
> how one prefers the main line to look.
Nope. The preferred way is to make the MR's commit as pretty as
possible. No final squashing.
Werner
