Opened 14 years ago
Closed 14 years ago
#7432 closed defect (fixed)
Why does trac-post-commit hook only work on master branch?
Reported by: | Owned by: | Herbert Valerio Riedel | |
---|---|---|---|
Priority: | normal | Component: | GitPlugin |
Severity: | normal | Keywords: | post-commit hook |
Cc: | stuge | Trac Release: | 0.12 |
Description
I confess that as a very new Trac user (using the git backend), I'm quite confused about what trac-admin changeset added
does and why it is needed or important, but I did notice that until I got repository_sync_per_request set properly, attempting to browse the head of a recently-pushed branch produced a nasty error message instead of displaying the diff. (The confusion is why it can't look up cache misses in raw git before displaying an error message; unlike svn, a git commit is immutable.)
Now, although repository_sync_per_request doesn't seem like a major performance bottleneck ATM, I was heeding the advice at GitPlugin and t:wiki:TracRepositoryAdmin and looking into using a post-receive hook to avoid a ~0.1s delay on each HTTP request, but I noticed that it filters out changesets not on the master branch.
The reason for this restriction is very unclear. I'd think this would cause my original problem to reappear. (I haven't explicitly tested it, but if I update only non-master branches, it won't do any explicit synchronization, and if I have auto-sync turned off, that puts me back to where I started.) Does it date from before multiple branch support (#789) was added?
I can imagine removing it might cause a bad interaction with the t:wiki:CommitTicketUpdater. I certainly don't mind ticket closing being limited to updates to a few named branches. (I.e. "fixes #12345" should close the bug when it's merged to master, rather than when it's pushed to the testing branch.)
That would seem to be a problem with all backends that support branches (including SVN), but git users tend to use branches far more aggressively, pushing a proposed fix to a branch in the repository for discussion rather than attaching a patch to a ticket.
Attachments (0)
Change History (5)
comment:1 Changed 14 years ago by
Severity: | minor → normal |
---|
comment:2 Changed 14 years ago by
Cc: | stuge added; anonymous removed |
---|
comment:3 Changed 14 years ago by
Replying to trac@horizon.com:
I confess that as a very new Trac user (using the git backend), I'm quite confused about what
trac-admin changeset added
does and why it is needed or important,
The reason why it's a good thing(tm) is, that it's a proper way to inject a new changeset into Trac's database; instead of having some unofficial self-made script which directly interacts with Trac's ticket database...
But there's some annoying issues with handling duplicate ticket changes which occur if branches get's merged and commits which were already injected get injected again causing duplicate ticket comments. So the easy fix was to restrict ticket updates only to some named branches. Furthermore, the script mentioned on the wiki page is just meant as an example to help you get going... :-)
comment:4 Changed 14 years ago by
I have added an example script that handle commits to all branches, for those who need it. It only process a changeset when it is introduced to the repository for the first time.
wiki:GitPlugin:trac-post-receive-hook-0.12-new-commits-from-all-branches.py
comment:5 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
I'm closing the ticket as it depends on the trac-post-receive, which implementation should be highly dependent on one's use case, and I have provided a hook that does what was requested in original ticket.
It gets worse. It's not only for branches, also multiple repos. At libusb.org we have several personal repositories and they should of course all be able to reference tickets, but only commits to the master branch of the main repo should be able to change ticket status.