From: "Shawn O. Pearce" <spearce@spearce.org>
To: Robin Rosenberg <robin.rosenberg@dewire.com>
Cc: git@vger.kernel.org
Subject: Re: [EGIT PATCH 4/7] Handle peeling of loose refs.
Date: Tue, 11 Nov 2008 10:23:58 -0800 [thread overview]
Message-ID: <20081111182357.GO2932@spearce.org> (raw)
In-Reply-To: <1226095664-13759-5-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> @@ -238,10 +235,19 @@ public ObjectId getObjectId() {
> * refer to an annotated tag.
> */
> public ObjectId getPeeledObjectId() {
> + if (peeledObjectId == ObjectId.zeroId())
> + return null;
> return peeledObjectId;
> }
>
> /**
> + * @return whether the Ref represents a peeled tag
> + */
> + public boolean isPeeled() {
> + return peeledObjectId != null && peeledObjectId != ObjectId.zeroId();
> + }
Huh. So peeledObjectId == ObjectId.zeroId() means what, exactly?
That we tried to peel this but we cannot because its not a tag?
What does a packed-refs record which has no peel data but which
is in a packed-refs with-peeled file have for peeledObjectId?
null or ObjectId.zeroId()?
> @@ -288,6 +289,28 @@ private void readOneLooseRef(final Map<String, Ref> avail,
> }
> }
>
> + Ref peel(final Ref ref) {
> + if (ref.isPeeled())
> + return ref;
I think you mean something more like:
if (ref.peeledObjectId != null)
return ref;
as the ref is already peeled, or at least attempted.
> + try {
> + Object tt = db.mapObject(ref.getObjectId(), ref.getName());
> + if (tt != null && tt instanceof Tag) {
> + Tag t = (Tag)tt;
> + while (t != null && t.getType().equals(Constants.TYPE_TAG))
> + t = db.mapTag(t.getTag(), t.getObjId());
> + if (t != null)
> + ref.setPeeledObjectId(t.getObjId());
> + else
> + ref.setPeeledObjectId(null);
> + } else
> + ref.setPeeledObjectId(ref.getObjectId());
> + } catch (IOException e) {
> + // Serious error. Caller knows a ref should never be null
> + ref.setPeeledObjectId(null);
> + }
> + return ref;
This whole block is simpler to write as:
try {
Object target = db.mapObject(ref.getObjectId(), ref.getName());
while (target instanceof Tag) {
final Tag tag = (Tag)target;
ref.setPeeledObjectId(tag.getObjId());
if (Constants.TYPE_TAG.equals(tag.getType()))
target = db.mapObject(tag.getObjId(), ref.getName());
else
break;
}
} catch (IOException e) {
// Ignore a read error. Callers will also get the same error
// if they try to use the result of getPeeledObjectId.
}
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> index 26748e2..4d6e6fd 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> @@ -939,6 +939,19 @@ public String getBranch() throws IOException {
> }
>
> /**
> + * Peel a possibly unpeeled ref and updates it. If the ref cannot be peeled
> + * the peeled id is set to {@link ObjectId#zeroId()}
But applications never see ObjectId.zeroId() because you earlier defined
getPeeledObjectId() to return null in that case. So why is this part of
the documentation relevant?
> + *
> + * @param ref
> + * The ref to peel
> + * @return The same, an updated ref with peeled info or a new instance with
> + * more information
> + */
> + public Ref peel(final Ref ref) {
> + return refs.peel(ref);
Can we tighten this contract? Are we always going to update the
current ref in-place, or are we going to return the caller a new
Ref instance? I'd like it to be consistent one way or the other.
If we are updating in-place then the caller needs to realize there
may be some cache synchronization issues when using multiple threads
to access the same Ref instances and peeling them. I.e. they may
need to go through their own synchornization barrier to ensure the
processor caches are coherent.
Given that almost everywhere else we treat the Ref as immutable
I'm tempted to say this should always return a new Ref object if we
peeled; but return the parameter if the parameter is already peeled
(or is known to be unpeelable, e.g. a branch head).
--
Shawn.
next prev parent reply other threads:[~2008-11-11 18:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-07 22:07 [J/E-GIT PATCH 0/7] Tag decoration v2 Robin Rosenberg
2008-11-07 22:07 ` [EGIT PATCH 1/7] Test the origName part of the key vs the ref itself Robin Rosenberg
2008-11-07 22:07 ` [EGIT PATCH 2/7] Add constant for "refs/" Robin Rosenberg
2008-11-07 22:07 ` [EGIT PATCH 3/7] Keep original ref name when reading refs Robin Rosenberg
2008-11-07 22:07 ` [EGIT PATCH 4/7] Handle peeling of loose refs Robin Rosenberg
2008-11-07 22:07 ` [EGIT PATCH 5/7] Add a method to get refs by object Id Robin Rosenberg
2008-11-07 22:07 ` [EGIT PATCH 6/7] Add tags to the graphical history display Robin Rosenberg
2008-11-07 22:07 ` [EGIT PATCH 7/7] Add decorate option to log program Robin Rosenberg
2008-11-11 18:28 ` [EGIT PATCH 6/7] Add tags to the graphical history display Shawn O. Pearce
2008-11-14 0:49 ` Robin Rosenberg
2008-11-11 18:32 ` Shawn O. Pearce
2008-11-14 23:24 ` [EGIT PATCH 1/7 v3] Add constant for "refs/" Robin Rosenberg
2008-11-14 23:24 ` [EGIT PATCH 2/7 v3] Keep original ref name when reading refs Robin Rosenberg
2008-11-14 23:24 ` [EGIT PATCH 3/7 v3] Test the origName part of the key vs the ref itself Robin Rosenberg
2008-11-14 23:24 ` [EGIT PATCH 4/7 v3] Handle peeling of loose refs Robin Rosenberg
2008-11-14 23:24 ` [EGIT PATCH 5/7 v3] Add a method to get refs by object Id Robin Rosenberg
2008-11-16 22:37 ` [EGIT PATCH 4/7 v3] Handle peeling of loose refs Shawn O. Pearce
2008-11-11 18:26 ` [EGIT PATCH 5/7] Add a method to get refs by object Id Shawn O. Pearce
2008-11-11 18:23 ` Shawn O. Pearce [this message]
2008-11-14 0:38 ` [EGIT PATCH 4/7] Handle peeling of loose refs Robin Rosenberg
2008-11-11 18:05 ` [EGIT PATCH 1/7] Test the origName part of the key vs the ref itself Shawn O. Pearce
2008-11-13 22:13 ` Robin Rosenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081111182357.GO2932@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=robin.rosenberg@dewire.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.