observing changes to a git repository

observing changes to a git repository

[Brian Swetland]

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

Re: observing changes to a git repository

[Jeff King]

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

> - 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

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.

> 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.

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

> 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.

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