On 21/10/13 07:58, Werner LEMBERG wrote:
I don't see a major simplification for the maintainer. The most
important action IMHO for contributing a patch is to rebase, ensuring
that the patch compiles with master. As far as I can see, github's
ticketing system doesn't allow to simply update the patch; instead,
you have to open a new ticket.
Not true at all. Rebase your branch, then,
git push -f origin my-branch
... will overwrite the contents of the pull request branch, and so update the
request itself. I've done it many times. :-)
Hopefully GitLab allows for similar functionality -- I will be checking this.
Lilypond's two-level approach with
separating issues from actual patches gives more consistency here.
Please correct me if I'm wrong.
GitHub has separate issues and pull requests, but there's automated coordination
between the two -- so submit a pull request titled "Fix Issue #102" (or with a
reference to Issue #102 in the description) the issue tracker will pick up on
the fact that such-and-such a pull request has referenced that issue; and
vice-versa if in an issue, I make reference to a commit or pull request.
As Carl noted, GitLab doesn't have that automated relationship yet, but it
should be arriving in the next release.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
