Modify

Opened 4 years ago

Closed 4 years ago

#7432 closed defect (fixed)

Why does trac-post-commit hook only work on master branch?

Reported by: trac@… Owned by: hvr
Priority: normal Component: GitPlugin
Severity: normal Keywords: post-commit hook
Cc: peter@… 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 4 years ago by peter@…

  • Severity changed from minor to normal

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.

comment:2 Changed 4 years ago by peter@…

  • Cc peter@… added

comment:3 in reply to: ↑ description Changed 4 years ago by hvr

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 4 years ago by silk

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 4 years ago by silk

  • Resolution set to fixed
  • Status changed from new to 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.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.