observing changes to a git repository

Assuming I wanted to use a script (possibly run from cron) to observe and report changes to a git repository (instead of running something from the various hooks), does the following strategy seem workable:

- for each branch to observe, record the initial position of that 
  branch (sha1 commit id) -- call this Last

- periodically:
  - grab the current head (call this Current)
  - if it's the same as Last stop
  - do a git log Current ^Last to observe what has happened since
    we last noticed a change.  report on these commits.
  - Last = Current

If these branches can be updated such that history is rewritten (not a concern in my particular case), I assume that for correctness you'd have to make Last and Current actual branches (perhaps under refs/heads/observer/... or whatever) to ensure that they don't get gc'd out from under you.

Am I correct in believing that the above strategy will (if history is not rewritten) correctly report all the commits between the last- observed and current state of the branch? Even if history *is* rewritten, I think (assuming I ensure things aren't gc'd) I'd get still get it right.

If I'm tracking several branches which can be merged between, I might want to keep track of which commits I've sent reports about if I don't want to re-report commits when they're merged into another branch.

Brian

On Mon, Dec 31, 2007 at 02:28:20PM -0800, Brian Swetland wrote:

Overall this makes sense. But in the case of history going backwards, you might want to show a log of "Current...Last". IOW, imagine this history:

  B-C
 /
A-D-E

Last is set to 'C' from some iteration of your script. In one period, somebody does a git-reset back to A, then makes commits D and E. So you want to see not just B and C, but some representation that D and E are no longer of interest. "gitk Last...Current" will show you a nice graph with a fork. git-log's --left-right option can represent the same information textually. What you want depends, I think, on the goal of your script.

Yes, although realistically the reflog will keep it intact (unless you have a bare repo without reflog).

What you have should work in the face of merges. Here's a history with some merges:

  B-C     H-I <-- branch1
 /   \   /   \
A-D-E-F-G-J-K-L <-- master

where 'F' and 'L' are our merges. Because ^H implies ^G, but not ^J, if we have something like Current=L, Last=H, you will see I, J, K, L.

So you will see each commit only once, unless you are running this script per-branch, in which case you will see it once per branch. :) In that case, you can do something like "git log Current ^LastBranch1 ^LastBranch2 ...". IOW, Last* indicates "I've seen this and don't care about it anymore".

-Peff