From: Joel Dice Date: Tue, 19 Sep 2006 22:24:31 GMT Subject: Re: Subversion-style incrementing revision numbers Message-ID: In-Reply-To: <20060919220011.GD8259@pasky.or.cz> On Wed, 20 Sep 2006, Petr Baudis wrote: > Dear diary, on Tue, Sep 19, 2006 at 11:42:20PM CEST, I got a letter > where Joel Dice 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 scenario I envision is several developers, each with a clone of a shared repository. The clones would not have IRNs turned on, only the shared repository. So, when I do a "git push", I get an IRN back, and I am not confused, because I know that IRN only applies to the shared repository. Then, when I mark a Bugzilla bug as fixed and attach the IRN to it, everybody knows that IRN refers to the shared repository. After all, I wouldn't mark the bug fixed if I had only committed it to my own private repository. I could also turn on IRNs on my clone if I really wanted, but not if I thought it would confuse myself or others. >> 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. That's what I figured. I should be able to walk the commit chain to get at all the commits in a push or fetch, right? - Joel