On Wed, Jul 25, 2012 at 02:52:54PM -0700, Junio C Hamano wrote:
> Paul Gortmaker <paul.gortma...@windriver.com> writes:
> > Has anyone else noticed false positives coming from the
> > orphan check?
> Thanks. This should fix it.
I've just been hunting the same bug and came up with the same answer.
Here's a commit message. Feel free to apply or steal text for your
-- >8 --
Subject: [PATCH] checkout: don't confuse ref and object flags
When we are leaving a detached HEAD, we do a revision
traversal to check whether we are orphaning any commits,
marking the commit we're leaving as the start of the
traversal, and all existing refs as uninteresting.
Prior to commit 468224e5, we did so by calling for_each_ref,
and feeding each resulting refname to setup_revisions.
Commit 468224e5 refactored this to simply mark the pending
objects, saving an extra lookup.
However, it confused the "flags" parameter to the
each_ref_fn clalback, which is about the flags we found
while looking up the ref (e.g., REF_ISSYMREF) with the
object flag (UNINTERESTING), leading to unpredictable
results, as we were setting random flag bits on objects in
builtin/checkout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index a76899d..f855489 100644
@@ -592,7 +592,7 @@ static int add_pending_uninteresting_ref(const char
const unsigned char *sha1,
int flags, void *cb_data)
- add_pending_sha1(cb_data, refname, sha1, flags | UNINTERESTING);
+ add_pending_sha1(cb_data, refname, sha1, UNINTERESTING);
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html