GitLab cross-posting to Trac?

Ben Gamari ben at
Sat Jan 5 22:03:01 UTC 2019

Richard Eisenberg <rae at> 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 <matthewtpickering at> 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.


>> Ticket numbers mentioned in commits also create references from
>> tickets to commits so you can click the hash to see what the commit
>> was.
>> <>
> 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.


- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <>

More information about the ghc-devs mailing list