Re: problem using jgit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Marek Zawirski <marek.zawirski@xxxxxxxxx> wrote:
> Marek Zawirski wrote:
>> Stephen Bannasch wrote:
>>> I've setup a simple test class that integrates jgit to clone a git  
>>> repository. However I'm getting a NullPointerError when  
>>> RevWalk.parseAny ends up producing a null object id.
...
> It's caused by 14a630c3: Cached modification times for symbolic refs too
> Changes introduced by this patch made Repository#getAllRefs() including  
> Ref objects with null ObjectId in case of unresolvable (invalid?) HEAD  
> symbolic ref, and null Ref for HEAD  when it doesn't exist. Previous  
> behavior was just not including such refs in result.

My intention here was that if a ref cannot be resolved, it should
not be reported.  So Ref.getObjectId should never return null, and
it should also never return an ObjectId for which the object does
not exist in the Repository's object database(s).  (Though that can
happen in the face of repository corruption, but lets not go there
just yet).

So IMHO the RefDatabase code is _wrong_ for returning HEAD with a
null objectId.

Now this case can happen if HEAD points at a stillborn branch.  This
is easily reproduced in any repository, e.g. just do:

	git symbolic-ref HEAD refs/heads/`date`

You'll wind up on a branch which doesn't exist.  In this case HEAD
shouldn't be reported back from RefDatabase, it doesn't exist, as
branch `date` does not exist either.

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux