Re: updating merge request

[Werner LEMBERG]

>> 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