threads / announce / 7228

[ANNOUNCE] chronoversion: chronological archiving script with temporary commits

Subject: [ANNOUNCE] chronoversion: chronological archiving script with temporary commits

## tl;dr

5 messages between Mar 13, 2007 and Mar 13, 2007.

replies: 4people: 4as markdown or json

David Tweed· Mar 13, 2007, 12:26 UTC · lore

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@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
Jakub Narebski· Mar 13, 2007, 15:42 UTC · re: David Tweed · lore

Re: [ANNOUNCE] chronoversion: chronological archiving script with temporary commits

[Cc: git@vger.kernel.org]
David Tweed wrote:
Show 5 quoted lines
> 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
By the way, do you have homepage for this project? If not, perhaps
you could write a few sentences on git wiki, e.g. at
  http://git.or.cz/gitwiki/Chronoversion
(linking it from http://git.or.cz/gitwiki/InterfacesFrontendsAndTools)
[...] 
> 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?

There is git-show-ref which was made because of introduction of packed refs, and there is git-for-each-ref which _might_ be used to avoid extra forking (extra calls).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Shawn O. Pearce· Mar 13, 2007, 15:45 UTC · re: David Tweed · lore

Re: [ANNOUNCE] chronoversion: chronological archiving script with temporary commits

David Tweed <david.tweed@gmail.com> wrote:
Show 14 quoted lines
> 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?

The common idiom if you want to compare trees to see if you need to make a commit is:

	oldc=`git rev-parse $tagname^{commit}`
	oldt=`git rev-parse $oldc^{tree}`
	newt`git write-tree`
	if [ X$oldt = X$newt ]; then
		: nothing to save
	else
		newc=`git commit-tree $newt -p $oldc`
		git update-ref $tagname $newc $oldc
	fi

Yes, a little ugly. But its safe; if another program were to alter the value of $tagname (e.g. "git branch -f", "git tag -f") while your script is running the update-ref in the else will fail, letting you know that $tagname changed in the process.

-- 
Shawn.
Johannes Schindelin· Mar 13, 2007, 15:49 UTC · re: Shawn O. Pearce · lore

Re: [ANNOUNCE] chronoversion: chronological archiving script with temporary commits

Hi,
On Tue, 13 Mar 2007, Shawn O. Pearce wrote:
Show 22 quoted lines
> David Tweed <david.tweed@gmail.com> wrote:
> > 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?
> 
> The common idiom if you want to compare trees to see if you
> need to make a commit is:
> 
> 	oldc=`git rev-parse $tagname^{commit}`
> 	oldt=`git rev-parse $oldc^{tree}`
> 	newt`git write-tree`
	new=`git write-tree`
Show 11 quoted lines
> 	if [ X$oldt = X$newt ]; then
> 		: nothing to save
> 	else
> 		newc=`git commit-tree $newt -p $oldc`
> 		git update-ref $tagname $newc $oldc
> 	fi
> 
> Yes, a little ugly.  But its safe; if another program were to
> alter the value of $tagname (e.g. "git branch -f", "git tag -f")
> while your script is running the update-ref in the else will fail,
> letting you know that $tagname changed in the process.

Ciao, Dscho

Johannes Schindelin· Mar 13, 2007, 15:54 UTC · re: Johannes Schindelin · lore

Re: [ANNOUNCE] chronoversion: chronological archiving script with temporary commits

Hi,
On Tue, 13 Mar 2007, Johannes Schindelin wrote:
Show 28 quoted lines
> Hi,
> 
> On Tue, 13 Mar 2007, Shawn O. Pearce wrote:
> 
> > David Tweed <david.tweed@gmail.com> wrote:
> > > 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?
> > 
> > The common idiom if you want to compare trees to see if you
> > need to make a commit is:
> > 
> > 	oldc=`git rev-parse $tagname^{commit}`
> > 	oldt=`git rev-parse $oldc^{tree}`
> > 	newt`git write-tree`
> 
> 	new=`git write-tree`
D'OH!
	newt=`git write-tree`
Oh, well...

← back to recent threads