Re: improving our workflow with better tools - let's test things.

[Joseph Rushton Wakeling]

On 21/10/13 14:30, Carl Sorensen wrote:
> In our current workflow, once I submit a patch, it's a fixed submission.
> I have to resubmit a different patch in order to change it.
>
> In the gitlab workflow, when I submit a merge request, it's a dynamic
> thing.  Any time I push my merge-request branch to origin, I'm changing
> the merge request.  (Oh -- I just saw the protection against unintended
> changes -- don't push the branch to origin!)

I found the opposite -- that whereas with GitHub any push to the feature branch 
updates the corresponding pull request, with GitLab that _doesn't_ happen; I had 
to manually click on the "Edit" button for GitLab to recognize that the head of 
the branch had changed, and then click "Save Changes" to update it.  But maybe 
this is a cosmetic issue and actually if I approved the merge, it would be the 
branch head that got merged.  I'll test.

On GitHub personally I find this auto-update of the pull request useful.  Apart 
from anything else, if you realize there's some small issue with what you 
submitted, it makes it trivial to fix, and it means you can have a fast 
turnaround between receiving reviewer feedback and responding to it with 
patches.  If you wind up with too many patches in the pull request, you can 
always rebase and squash stuff before the branch is merged.

More broadly, in the GitHub-style workflow (which GitLab is copying) it's a good 
rule of thumb to assume, "Don't push anything to any public branch unless you 
intend for other people to see and use it."