[ANNOUNCE] chronoversion: chronological archiving script with temporary commits

[David Tweed]

Hi, I believe that I've now got temporary commits (for bookkeeping,
hi-granularity bisecting recent changes) working, so I'm just
mentioning there's a new version of chronoversion at

http://www.personal.rdg.ac.uk/~sis05dst/chronoversion.tgz

It maintains two parallel branches, master and temp, using temp for
high-granularity temporary commits that can be cleaned away at any
time. When a filetree state needs to be recorded on both branches it
doesn't merge branches but instead writes a commit tree and then
writes commit objects using that tree on both branches. Note: I don't
completely understand what all the low-level git stuff is supposed to
do so this code was experimented with until it appears to work.
Consequently, be very careful about entrusting any hyper-important
data to this.

A question for those who understand things: I stash the last written
_tree_'s hash in a tag and then when a new "commit's" directory tree
is written starts look to see if it's the same SHA value. If it is I
know I can avoid the commit. At the moment I'm using

    if os.path.exists(lastTreeFile) and
tree==open(lastTreeFile,"r").read()[:40]:

to be safe just in case a user, eg, goes mad and manually deletes that
record. Clearly this is going to hit trouble if git ever decides to
put this tag into a packed refs file.
Is there any neat way of using builtin stuff like git-rev-parse to ask
if a ref has a given SHA1 value and return an easily parsed yes/no
answer?

As a side note to Jon Smirl: I think kernel development is relatively
special in that you really can't safely test things at the same time
as you're editing the code (since clearly a kernel hang/oops/whatever
is possible). However, as I work on userspace programs I quite often
have my monte-carlo simulation code running on all the cores at the
same I edit its source code to try and refine it for the next run. So
in general if using git is "free" it'll be because editing tools and
git take tiny portions of current CPU's power rather than because
there're unused cores :-) (Actually, that's a serious point: I did put
in some thought into chronoversion to try and minimise its cpu usage
so it intruded as little as possible.)
-- 
cheers, dave tweed__________________________
david.tweed at gmail.com
Rm 124, School of Systems Engineering, University of Reading.
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html