[git] automatic ticket closing

Joaquin M Lopez Munoz

4 Dec 2013 4 Dec '13

9:57 p.m.

Trac has this nice feature by which one can close a ticket merely by indicating its #number in the associated fix commit message. Is there anything similar for Git? Plans to add it to our Trac environment? Thank you, Joaquín M López Muñoz Telefónica Digital

Show replies by date

Gavin Lambert

4 Dec 4 Dec

10:40 p.m.

On 5/12/2013 10:57, Quoth Joaquin M Lopez Munoz:

...

Trac has this nice feature by which one can close a ticket merely by indicating its #number in the associated fix commit message. Is there anything similar for Git? Plans to add it to our Trac environment?

I don't know about Trac, but with GitHub-based issues you can reference an issue by #number or commit via SHA and it will put the appropriate links in on both ends automagically. You can also use "closes #number" or "fixes #number" or a few other variations to automatically close the issue when the commit lands.

Mateusz Loskot

11:26 p.m.

On 4 December 2013 22:40, Gavin Lambert wrote:

...

On 5/12/2013 10:57, Quoth Joaquin M Lopez Munoz:

...
Trac has this nice feature by which one can close a ticket merely by indicating its #number in the associated fix commit message. Is there anything similar for Git? Plans to add it to our Trac environment?

I don't know about Trac, but with GitHub-based issues you can reference an issue by #number or commit via SHA and it will put the appropriate links in on both ends automagically. You can also use "closes #number" or "fixes #number" or a few other variations to automatically close the issue when the commit lands.

https://help.github.com/articles/closing-issues-via-commit-messages Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net

Daniel James

11:33 p.m.

On 4 December 2013 23:26, Mateusz Loskot wrote:

...

On 4 December 2013 22:40, Gavin Lambert wrote:

...
On 5/12/2013 10:57, Quoth Joaquin M Lopez Munoz:

...
Trac has this nice feature by which one can close a ticket merely by indicating its #number in the associated fix commit message. Is there anything similar for Git? Plans to add it to our Trac environment?

I don't know about Trac, but with GitHub-based issues you can reference an issue by #number or commit via SHA and it will put the appropriate links in on both ends automagically. You can also use "closes #number" or "fixes #number" or a few other variations to automatically close the issue when the commit lands.

https://help.github.com/articles/closing-issues-via-commit-messages

I think the plan is to continue using trac issues for the immediate future. There is a git plugin available for it, so I assume we can continue using comments as before once that's set up.

Beman Dawes

11:53 p.m.

On Wed, Dec 4, 2013 at 6:33 PM, Daniel James wrote:

...

...
On 4 December 2013 22:40, Gavin Lambert wrote:

...
On 5/12/2013 10:57, Quoth Joaquin M Lopez Munoz:

...
Trac has this nice feature by which one can close a ticket merely by indicating its #number in the associated fix commit message. Is

...
...
...
anything similar for Git? Plans to add it to our Trac environment?

I don't know about Trac, but with GitHub-based issues you can reference an issue by #number or commit via SHA and it will put the appropriate

On 4 December 2013 23:26, Mateusz Loskot wrote: there links in

...
...
on both ends automagically. You can also use "closes #number" or "fixes #number" or a few other variations to automatically close the issue when the commit lands.

https://help.github.com/articles/closing-issues-via-commit-messages

I think the plan is to continue using trac issues for the immediate future. There is a git plugin available for it, so I assume we can continue using comments as before once that's set up.

That was definitely the plan. But I'm using the GitHub issues system to process Admin requests for write permissions, and that is altering my perceptions. I think the same thing is happening as happened with Git itself. You can speculate about whether A is better than B all you want, but actually using something alters your perspective. If I had to put my finger on what is was in the case of the issues lists, I would say the responsiveness of the GitHub issue tracker. But whatever it is, something is making me want to abandon the old trac issue tracker ASAP. --Beman

Bjorn Reese

5 Dec 5 Dec

9 a.m.

On 12/05/2013 12:53 AM, Beman Dawes wrote:

...

I think the same thing is happening as happened with Git itself. You can speculate about whether A is better than B all you want, but actually using something alters your perspective. If I had to put my finger on what is was in the case of the issues lists, I would say the responsiveness of the GitHub issue tracker. But whatever it is, something is making me want to abandon the old trac issue tracker ASAP.

Please notice that the GitHub issue tracker does not allow you to attach patches (you can only attach graphics.) This raises the question if the only way to contribute will be through GitHub pull requests. While these certainly are convenient to the maintainers, they do require extra work for the casual contributor: https://help.github.com/articles/syncing-a-fork

Daniel James

9:32 a.m.

On 5 December 2013 09:00, Bjorn Reese wrote:

...

On 12/05/2013 12:53 AM, Beman Dawes wrote:

...
I think the same thing is happening as happened with Git itself. You can speculate about whether A is better than B all you want, but actually using something alters your perspective. If I had to put my finger on what is was in the case of the issues lists, I would say the responsiveness of the GitHub issue tracker. But whatever it is, something is making me want to abandon the old trac issue tracker ASAP.

Please notice that the GitHub issue tracker does not allow you to attach patches (you can only attach graphics.)

I don't know if it was deliberate, but Beman didn't say that the replacement has to be github. We could possibly use redmine or something else.

Niall Douglas

9:37 a.m.

On 5 Dec 2013 at 10:00, Bjorn Reese wrote:

...

Please notice that the GitHub issue tracker does not allow you to attach patches (you can only attach graphics.)

There is an easy, albeit non-obvious, workaround for the initiated: use github gists for submitting patches. See https://github.com/ned14/nedmalloc/issues/1 for an example sticky note telling people using Github issues what to do. I agree for any substantial patch a pull request from a fork is much easier. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

Mateusz Loskot

10:01 a.m.

On 5 December 2013 09:00, Bjorn Reese wrote:

...

On 12/05/2013 12:53 AM, Beman Dawes wrote:

...
I think the same thing is happening as happened with Git itself. You can speculate about whether A is better than B all you want, but actually using something alters your perspective. If I had to put my finger on what is was in the case of the issues lists, I would say the responsiveness of the GitHub issue tracker. But whatever it is, something is making me want to abandon the old trac issue tracker ASAP.

Please notice that the GitHub issue tracker does not allow you to attach patches (you can only attach graphics.)

This raises the question if the only way to contribute will be through GitHub pull requests. While these certainly are convenient to the maintainers, they do require extra work for the casual contributor:

OTOH, it prevents casual contributor from being lazy and generating a diff against random revision or unknown version of sources shifting the hassle to maintainer who has to manually review and apply the patch line by line. On GitHub, one may almost prepare and submit the whole patch with a bunch of clicks, while holding a coffee cup in the other hand. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net

Steven Watanabe

4:21 p.m.

AMDG On 12/05/2013 02:01 AM, Mateusz Loskot wrote:

...

On 5 December 2013 09:00, Bjorn Reese wrote:

...
This raises the question if the only way to contribute will be through GitHub pull requests. While these certainly are convenient to the maintainers, they do require extra work for the casual contributor:

OTOH, it prevents casual contributor from being lazy and generating a diff against random revision or unknown version of sources shifting the hassle to maintainer who has to manually review and apply the patch line by line.

I can't speak for any other maintainers, but I usually do this anyway. I rarely apply patches without any modification and I always review the entire patch first.

...

On GitHub, one may almost prepare and submit the whole patch with a bunch of clicks, while holding a coffee cup in the other hand.

In Christ, Steven Watanabe

Steven Watanabe

4:28 p.m.

AMDG On 12/05/2013 01:00 AM, Bjorn Reese wrote:

...

On 12/05/2013 12:53 AM, Beman Dawes wrote:

...
I think the same thing is happening as happened with Git itself. You can speculate about whether A is better than B all you want, but actually using something alters your perspective. If I had to put my finger on what is was in the case of the issues lists, I would say the responsiveness of the GitHub issue tracker. But whatever it is, something is making me want to abandon the old trac issue tracker ASAP.

Please notice that the GitHub issue tracker does not allow you to attach patches (you can only attach graphics.)

Patches aren't the only use for attachments. Test cases are also common (and absolutely critical). If the github issue tracker doesn't support attachments, then it's simply a non-starter.

...

This raises the question if the only way to contribute will be through GitHub pull requests. While these certainly are convenient to the maintainers, they do require extra work for the casual contributor:

https://help.github.com/articles/syncing-a-fork

In Christ, Steven Watanabe

Cox, Michael

11:34 p.m.

On Thu, Dec 5, 2013 at 9:28 AM, Steven Watanabe wrote:

...

AMDG

On 12/05/2013 01:00 AM, Bjorn Reese wrote:

...
On 12/05/2013 12:53 AM, Beman Dawes wrote:

...
I think the same thing is happening as happened with Git itself. You can speculate about whether A is better than B all you want, but actually using something alters your perspective. If I had to put my finger on what is was in the case of the issues lists, I would say the responsiveness of the GitHub issue tracker. But whatever it is, something is making me want to abandon the old trac issue tracker ASAP.

Please notice that the GitHub issue tracker does not allow you to attach patches (you can only attach graphics.)

Patches aren't the only use for attachments. Test cases are also common (and absolutely critical). If the github issue tracker doesn't support attachments, then it's simply a non-starter.

I'm assuming by the term test cases that means Boost.Test unit-tests. Wouldn't be more convenient to see the modified/new unit-tests for a library code change in the pull-request?

...

...
This raises the question if the only way to contribute will be through GitHub pull requests. While these certainly are convenient to the maintainers, they do require extra work for the casual contributor:

https://help.github.com/articles/syncing-a-fork

In Christ, Steven Watanabe

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Lars Viklund

6 Dec 6 Dec

8:03 a.m.

On Thu, Dec 05, 2013 at 04:34:52PM -0700, Cox, Michael wrote:

...

On Thu, Dec 5, 2013 at 9:28 AM, Steven Watanabe wrote:

...
Patches aren't the only use for attachments. Test cases are also common (and absolutely critical). If the github issue tracker doesn't support attachments, then it's simply a non-starter.

I'm assuming by the term test cases that means Boost.Test unit-tests.

A test case as in a minimal piece of end user application code that demonstrates a problem. It may be retrofitted into an actual Boost.Test testcase once there is a clear solution to it, but that's a significant burden to put on an end user that just wants to report a bug with reproduction instructions.

...

Wouldn't be more convenient to see the modified/new unit-tests for a library code change in the pull-request?

Convenient, sure. Practically doable by end users unfamiliar with the Boost codebase and Boost.Test? Not really. If I'm not wrong, the discussion is about end-user issues as well, not just patch requests. -- Lars Viklund | zao@acc.umu.se

Paul A. Bristow

8:53 a.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Lars Viklund Sent: Friday, December 06, 2013 8:04 AM To: boost@lists.boost.org Subject: Re: [boost] [git] automatic ticket closing

On Thu, Dec 05, 2013 at 04:34:52PM -0700, Cox, Michael wrote:

...
On Thu, Dec 5, 2013 at 9:28 AM, Steven Watanabe wrote:

...
Patches aren't the only use for attachments. Test cases are also common (and absolutely critical). If the github issue tracker doesn't support attachments, then it's simply a non-starter.

I'm assuming by the term test cases that means Boost.Test unit-tests.

A test case as in a minimal piece of end user application code that demonstrates a problem.

It may be retrofitted into an actual Boost.Test testcase once there is a clear solution to it, but

that's a

...

significant burden to put on an end user that just wants to report a bug with reproduction instructions.

...
Wouldn't be more convenient to see the modified/new unit-tests for a library code change in the pull-request?

Convenient, sure. Practically doable by end users unfamiliar with the Boost codebase and Boost.Test? Not really.

If I'm not wrong, the discussion is about end-user issues as well, not just patch requests.

Definitely. It's really important that users find it easy to report things - even anonymously. Adding demos of what is wrong, real test cases, fixes, screen shots... must be *easy*. Trac is discouraging enough - the GIT mechanism sounds more intimidating. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

Mateusz Loskot

9:01 a.m.

On 6 December 2013 08:53, Paul A. Bristow wrote:

...

...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Lars Viklund Sent: Friday, December 06, 2013 8:04 AM To: boost@lists.boost.org Subject: Re: [boost] [git] automatic ticket closing

On Thu, Dec 05, 2013 at 04:34:52PM -0700, Cox, Michael wrote:

...
On Thu, Dec 5, 2013 at 9:28 AM, Steven Watanabe wrote:

...
Patches aren't the only use for attachments. Test cases are also common (and absolutely critical). If the github issue tracker doesn't support attachments, then it's simply a non-starter.

I'm assuming by the term test cases that means Boost.Test unit-tests.

A test case as in a minimal piece of end user application code that demonstrates a problem.

It may be retrofitted into an actual Boost.Test testcase once there is a clear solution to it, but that's a significant burden to put on an end user that just wants to report a bug with reproduction instructions.

...
Wouldn't be more convenient to see the modified/new unit-tests for a library code change in the pull-request?

Convenient, sure. Practically doable by end users unfamiliar with the Boost codebase and Boost.Test? Not really.

If I'm not wrong, the discussion is about end-user issues as well, not just patch requests.

Definitely. It's really important that users find it easy to report things - even anonymously. Adding demos of what is wrong, real test cases, fixes, screen shots... must be *easy*. Trac is discouraging enough - the GIT mechanism sounds more intimidating.

One of the main feature of GitHub (BitBucket as well) is that they wrap all the Git mechanisms with a very friendly UI that also supports developers integrating codebase with ticketing system as well as basic inline code reviews. Disclaimer: I'm not advocating switch to GitHub Issues, just pointing out that in comparison to GitHub, Trac feels discouraging indeed. On the other hand, there are disintegrated infrastructure like the one Qt folks use, I've experienced it lately: Gitorious (Git repository) + JIRA (bug tracker) + Gerrit (code reviews) Qt setup feels to me like a dense forest to a bat with broken ears. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net

3992

Age (days ago)

3994

Last active (days ago)

List overview

Download

14 comments

11 participants

participants (11)

Beman Dawes
Bjorn Reese
Cox, Michael
Daniel James
Gavin Lambert
Joaquin M Lopez Munoz
Lars Viklund
Mateusz Loskot
Niall Douglas
Paul A. Bristow
Steven Watanabe