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 <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 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
-
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