[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    observing changes to a git repository
From:       Brian Swetland <swetland () google ! com>
Date:       2007-12-31 22:28:20
Message-ID: 20071231222820.GA11278 () bulgaria ! corp ! google ! com
[Download RAW message or body]


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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]