Re: Tracking branch history

From: Shawn Pearce <spearce@spearce.org>
Date: May 13, 2006, 03:40 UTC
Message-ID: <20060513034051.GA21586@spearce.org>
In-Reply-To: <Pine.LNX.4.64.0605121640210.3866@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> wrote:

Show 23 quoted lines

> 
> On Fri, 12 May 2006, Daniel Barkalow wrote:
> >
> > One feature that might make git more intuitive to people is if we were to 
> > additionally track the history of what commit was the head of each branch 
> > over time. This is only vaguely related to the history of the content, but 
> > it's well-defined and sometimes significant.
> > 
> > E.g., if you know that two weeks ago, what you had worked, but it doesn't 
> > work now, you can use git-bisect to figure out what happened, but first 
> > you have to figure out what commit it was that you were using two weeks 
> > ago. Two weeks ago, we had that information, but we didn't keep it.
> 
> Note that this is possible, but it must be done literally as a separate 
> history from the commit history. 
> 
> IOW, a good (?) way to do it is to literally have a commit hook that 
> basically just does
> 
> 	echo $new >> .git/$branch-commit-history
> 
> possibly together with a datestamp thing (ie it could be something like
> "echo $new "$USER" $(date)" rather than just the commit SHA1).

Why not intergrate this into git-update-ref. Almost every tool which deals with a GIT repository (aside from my pure-Java Eclipse plugin which is still a major work-in-process) performs ref changes through git-udpate-ref. So just have it append the ref's history to a file:

	.git/log/refs/heads/$branch

where the history records are stored as:

	40 byte commit-ish SHA1
	<SP>
	<committer>
	<LF>

e.g.:

	cbb6d91d95e523c2b6a6b52577c4be28d18ace83 Shawn O. Pearce <spearce@spearce.org> 1137039378 -0500
	ae8c74e96a1e02bbfb7f1a9669b77d6f8ee6c3cf Shawn O. Pearce <spearce@spearce.org> 1136921470 -0500

Of course a major issue here is locking the log file during the ref update, but it looks like it might just be safe to append the entry to the log file right after the re_verify and before the rename.

I wouldn't have git-update-ref create the log file. I'd would only have it append if the log already exists.

Hmm, this actually looks like it would be really easy. Maybe I'll hack up an RFC patch this evening after dinner.

-- 
Shawn.