CommitTicketUpdater - git and replayed commits

[pferreir]

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…

[anonymous]

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.

[Remy Blank]

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.

[Pedro Ferreira <ilzogoiby@…>]

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

[Matthijs Kooijman <matthijs@…>]

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.

[anonymous]

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.

[anonymous]

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.