Re: GitLab cross-posting to Trac?

Richard Eisenberg writes:

I second Simon's "super-helpful". But we don't need to exactly copy Trac's behavior. If there is a clear link to the e.g. commit with message, that's fine too.

...

On Jan 5, 2019, at 3:47 AM, Matthew Pickering wrote:

As from now all patches will be merged via gitlab it is unnecessary as related merge requests

We're not using GitLab ticketing yet, but I understand we will. When you say "related merge requests", does that include *issues*?

GitHub does this, so I imagine it does, but we should make sure. In other words, if we make an MR that references an issue, will the issue show this fact? What if the MR text doesn't reference an issue, but the commit message does?

In both cases a note will be left on the referenced issue.

For example, many of my patches are targeted toward one issue, but fix several others on the way. The MR text will probably mention only the main issue, but the commit message will mention the others. Will the others automatically be cross-referenced? Or will I be forced to copy these auxiliary issues into the MR text for proper cross-referencing?

I believe in GitHub, the cross-referencing happens at *mentions*.

I think that means we would get it upon posting the MR and upon the use of an issue number in a comment. But does anything happen at a *merge*? That is, suppose the fix for #12345 gets posted and debated at some length. The #12345 issue will get linked to the MR. Then, all is ready and we click the "merge when green" button. Some hours later, the MR is merged. Does the issue get updated then?

Yes, when the commit is merged to master a note of the form "mentioned in commit abcde" will appear on the issue. The SHA is a link and the commit title is shown when one hovers over it.

...

show up visually on each ticket and when a patch is merge the ticket is automatically closed.

By "ticket", do you mean issue or MR? I assume you mean MR, and I like this behavior. But I hope you don't mean issue. It's quite common to push a patch materially affecting an issue but not closing it, and I think the manual step to close the issue separately is worthwhile.

By default GitLab can automatically close issues mentioned by a commit pushed to the `master` branch. However, not all mentioned will result in closure; rather, only those matching one of a set of patterns [1]. I personally find the default set of patterns a bit scary. For instance, I found that a commit containing the string "doesn't fix #NNNN" actually results in #NNNN being closed [2]. For this reason I think we really want to change or entirely disable [3] this behavior. [1] https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html [2] https://gitlab.com/gitlab-org/gitlab-ce/issues/55970 [3] https://docs.gitlab.com/ee/administration/issue_closing_pattern.html

...

Ticket numbers mentioned in commits also create references from tickets to commits so you can click the hash to see what the commit was.

https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655 https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655

One small point of nomenclature I'd like to clarify/propose:

- Merge Request (MR): A proposed patch. The new form of a Phab Diff. - Issue: An infelicity or task to be completed. The new form of a Trac Ticket. - Ticket: ?. I propose: Either an MR or an issue.

Hmm, I generally have used "ticket" and "issue" interchangeably. I suppose we could repurpose it as you propose; I'm not sure which is less confusing. In general I think I will probably just avoid using the term after the migration. Cheers, - Ben