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