trac-pre-commit-hook and trac-post-commit-hook should be more lenient about keywords.

[pfnguyen@…]

When one wishes to reference a ticket using the commit hooks, it's a pain in the ass to have to remember a specific keyword (command) to specify prior to the ticket number when referencing a ticket. When closing I don't mind using the close or fix keywords, but for all other cases, I see having to specify re, see, addresses, for, etc. superfluous.

I propose that simply mentioning the ticket number (in the form of #number or ticket:number) be sufficient for default, ticket number mentioned for pre-commit or inclusion into ticket comment for post-commit, processing.

Closing or marking a ticket as closed should require the close keywords.

[pfnguyen@…]

simple diff implementing what I describe above

[anonymous]

toss in a milestone again, considering how trivial this is…

[Emmanuel Blot]

IMHO, there a lot of different usages and expectations of the trac-* scripts.

That's why there are located in the "contrib" directory: you can customize the scripts the way you want, but other users may not want to use the scripts the same way than you do. I don't, as a matter of fact. For instance, I've re-written these scripts to use Python wrappers instead of spwaning a couple of "svn" subprocesses, and add a couple of others "commands".

This ticket is a good place to keep the different proposed patches to the contrib scripts, but they may stay as patches instead of being integrated to the official release.

I think that if cmlenz has cleared up the target milestone, it means that the developers have no plan to look at it for the next release.

[anonymous]

Well, if the trac-pre/post hooks are supposed to stand as examples, at least they should be consistent.

The provided example of the pre-commit does not match the "behavior" of the post-commit hook. Rather, one can use commands with the post-commit hook that will not pass the pre-commit hook.

At the very least, the command set between the two hooks should be the same. For example: fix, close, fixed, closed in post-commit but not allowed in pre-commit. As well, as a tracking system with "minimal" impact, it would be nice if the command words were as lenient as possible. I have no argument against supporting specific command words, but for basic functionality, it should be simple.

[Christian Boos]

What you're trying to achieve here is #508 (Related checkins). However, that would be a rather brute force way to do it. TracCrossReferences provides that functionality, and doesn't clutter the ticket history with those references to related checkins, rather they are displayed on a specific page reachable by a Cross-References page navigation link (available on every page, btw).

Though the development of TracCrossReferences has stalled a bit, it will be updated in the upcoming weeks, and I don't want to see a widespread use of workarounds in the meantime… In the same thinking, I don't think that the majority of people using the trac-post-commit-hook would like to have every reference to their tickets added as comment. I'd expect them willing to have a way to keep control (we can even be stricter on what we reference, using --require-envelope, on trunk).

This makes me think that your patch would eventually be acceptable if it introduced a --lenient mode, playing well with the rest (please do it for trunk, not for 0.9-stable).

I move the milestone to 0.11, but it may still make it for 0.10 if the patch is good and here in duly time (no pressure ;) )

[Christian Boos]

As explained above, the trac-post-commit-hook is not the place to implement #508.