Re: Subversion-style incrementing revision numbers
- From
- Joel Dice <dicej@mailsnare.net>
- Date
- Sep 19, 2006, 22:24 UTC
- Message-ID
- <Pine.LNX.4.62.0609191609090.9752@joeldicepc.ecovate.com>
- In-Reply-To
- <20060919220011.GD8259@pasky.or.cz>
On Wed, 20 Sep 2006, Petr Baudis wrote:
Show 18 quoted lines
> Dear diary, on Tue, Sep 19, 2006 at 11:42:20PM CEST, I got a letter > where Joel Dice <dicej@mailsnare.net> 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.
Show 8 quoted lines
>> 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