Dear diary, on Tue, Sep 19, 2006 at 11:42:20PM CEST, I got a letter where Joel Dice <dicej@xxxxxxxxxxxxx> said that... > On Tue, 19 Sep 2006, Petr Baudis wrote: > >Also, multiple IRNs could refer to a single real commit if you do e.g. > >cg-admin-uncommit, since revlog logs revision updates, not new revisions > >created. This may or may not be considered a good thing. If you rather > >want to just create a new IRN at commit object creation time, also note > >that some tools _might_ validly create commit objects and then throw > >them away, which would generate non-sensical (and after prune, invalid) > >IRNs. > > I'm not too worried about cg-admin-uncommit or git-reset, since the IRN > feature is intended mainly for shared repositories. I would suggest that > such commands simply be disallowed for such repositories. What kind of shared repositories? You yourself said that IRNs are local to a repository, thus they are not preserved over cloning/fetching from a repository, if you mean that. > The problem of temporary commits certainly needs to be addressed. In this > case, may I assume nothing under $GIT_DIR/refs is ever modified? If so, > perhaps I could somehow hook into the git-update-ref step. Is that what > the revlog code does? Yes. But not every commit is always recorded to something in refs/. The simplest case is if you fetch from a remote repository (or push to your repository), only the latest commit is recorded. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Snow falling on Perl. White noise covering line noise. Hides all the bugs too. -- J. Putnam - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html