Edgewall Software

Opened 11 years ago

Last modified 7 years ago

#9495 new enhancement

CommitTicketUpdater - git and replayed commits

Reported by: pferreir Owned by:
Priority: normal Milestone: unscheduled
Component: ticket system Version: 0.12dev
Severity: normal Keywords: CommitTicketUpdater
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:


I do all my development over two branches, a stable one and an experimental one, which I merge periodically. So, each time I merge stable into experimental, commits from stable are again passed on to the ticket updater. So, sometimes this ends up producing duplicate comments and the ticket being closed twice…

My opinion is that could be an option that would somehow trigger the detection of duplicate commits and ignore them. I'm not very sure how to do this, if I should check if there's already a comment with the given commit sha1 associated with the ticket (kind of hacky), or checking the past repository history (ignoring the last changeset) for the commit (not sure how fast it will be).

I would be willing to produce a patch for that, if you believe this is something worth investing time on. Otherwise, I can just try changing a bit my commit hook. However, I believe that this will be a problem with most distributed VCs, so…

Attachments (0)

Change History (7)

comment:1 by anonymous, 11 years ago

How about extending on the existing ticket updater and provide a special version that can be used with for example git or other, similar repository backends?

The current ticket updater works fine for subversion like repositories, so it actually would need not be patched.

E.g. class GitTicketUpdater(TicketUpdater) … and override replace the methods that you need.

That way, people could choose between your ticket updater and the originally provided one.

This way, also, we could extend upon the existing ticket updater behaviour in order to make it specific to either SVN, GIT or whatever repository backend is being supported.

This, however, would require a small framework and detection of the actual type of repository being worked upon.

comment:2 by Remy Blank, 11 years ago

Milestone: unscheduled

The CommitTicketUpdater should already be quite easy to extend by subclassing, so you could have a go at it for your own use. If the changes make sense for other VC backends (and I assume they would), we should easily be able to integrate them.

comment:3 by Pedro Ferreira <ilzogoiby@…>, 11 years ago

OK, I will give it a try, then ;)

comment:4 by Matthijs Kooijman <matthijs@…>, 11 years ago

Wouln't it make sense to instead work only on commits in a specific (configurable) branch? I mean, if you have an experimental branch, it doesn't make sense to close a ticket when it gets committed there. Only when it gets merged into the stable branch and is actually certain to end up in a release, the ticket should be closed (all of this dependent on your actual workflow, of course). It's probably useful to allow a list of branchnames or even regexes for this, though.

If you want to do duplicate commit detection instead, it's probably not the best course to ignore duplicate commits. Instead, having a short comment that says "commit a92b92c has been merged to branch master" might be a lot more useful, so people can actually track commits as well.

Combining the above ideas might be even more perfect: Add a comment for every commit that references a ticket, but only actually close a ticket when a "Closes" commit is committed to a configurable "stable" branch.

comment:5 by Jun Omae, 8 years ago

Keywords: CommitTicketUpdater added

comment:6 by anonymous, 7 years ago

That last suggestion doesn't work for our workflow. We mark tickets closed when we are done working on them, even if they haven't been merged to a stable branch yet. Sometimes our project branches can persist a month or three before being merged and we still want to keep track of which tasks have been completed and which haven't.

Has anyone implemented a plugin for this yet? I'm thinking the simple approach is extending CommitTicketUpdater to check if the revision hash being processed exists in the comments for this ticket yet. I do like the idea of changing the comment to "merged to BRANCH" when this is detected, but adding a second copy of the comment to the ticket certainly doesn't seem very useful, especially when the comment doesn't include the destination branch name.

comment:7 by anonymous, 7 years ago

May not need a plugin or a fix. I was using a very simple post-receive script I found on StackOverflow. When I use the post-receive script from the trac wiki, this works fine.

Modify Ticket

Change Properties
Set your email in Preferences
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.