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."
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
