Re: Creating something like increasing revision numbers

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 19, 2009, 02:41 UTC
Message-ID: <alpine.LNX.2.00.0910182140440.14365@iabervon.org>
In-Reply-To: <20091019013320.GD17397@gamma.logic.tuwien.ac.at>

On Mon, 19 Oct 2009, Norbert Preining wrote:

Show 22 quoted lines

> Hi Daniel,
> 
> On So, 18 Okt 2009, Daniel Barkalow wrote:
> > > - how would one access this "sequence" number on the server
> > 
> > There isn't currently anything built in that counts up like that; however, 
> > it shouldn't be too hard to add something, because the reflog gets an 
> > entry at the same times the sequence number would increase. In fact, you 
> 
> Ok.
> 
> > > - is there a way to determine at which of this "sequence" numbers a specific
> > >   file has been changed last?
> > 
> > There isn't a built-in way, but you can find the current hash for a 
> > filename with "git ls-tree -r <branch> <filename>", and find the hash as 
> > of N changes ago with "git ls-tree -r <branch>@{<N>} <filename>". You're 
> > looking for the smallest N where they don't match. (And you probably 
> > don't want to be a binary search or the like, because that might miss that 
> 
> That sounds like we cannot use that, because we have to do that for about
> 80k files and that on each (at least daily) rebuilt. That is not feasable.

It's likely to be much more efficient (and maybe sufficiently efficient) to do them all in a single pass. In fact, it should be easy enough to keep a cache of the latest numbers for the files, and update that to change the value for those files that differ between the old commit and the new commit in the post-update hook.

	-Daniel
*This .sig left intentionally blank*