libgit2: Cannot look up tag object

[nomeata]

trafficstars

Hi,

I’m stuck with my program aborting with the not very helpful error message jww (2013-07-08): NYI. Some googleing showed me that this is simply not supported yet:

lgLookupObject :: MonadLg m
               => Oid
               -> ReaderT LgRepo m (Git.Object LgRepo (ReaderT LgRepo m))
lgLookupObject oid = do
    (oid', typ, fptr) <-
        lookupObject' (getOid oid) (getOidLen oid)
            (\x y z   -> c'git_object_lookup x y z c'GIT_OBJ_ANY)
            (\x y z l -> c'git_object_lookup_prefix x y z l c'GIT_OBJ_ANY)
            $ \coid fptr y -> do
                typ <- liftIO $ c'git_object_type y
                return (mkOid coid, typ, fptr)
    case () of
        () | typ == c'GIT_OBJ_BLOB   ->
                Git.BlobObj <$> lgObjToBlob (Tagged oid') (castForeignPtr fptr)
           | typ == c'GIT_OBJ_TREE   ->
                -- A ForeignPtr C'git_object is bit-wise equivalent to a
                -- ForeignPtr C'git_tree.
                return $ Git.TreeObj (LgTree (Just (unsafeCoerce fptr)))
           | typ == c'GIT_OBJ_COMMIT ->
                Git.CommitObj <$>
                liftIO (withForeignPtr fptr $ \y ->
                         lgObjToCommit (Tagged oid') (castPtr y))
           | typ == c'GIT_OBJ_TAG -> error "jww (2013-07-08): NYI"
           | otherwise -> error $ "Unknown object type: " ++ show tye

Can this be fixed? Is there a better way to resolve a possibly annotated tag to its commit?

[jwiegley]

Yes, it can be fixed, it just needs the code to be written. ;)

[jwiegley]

@nomeata Btw, I've started on version 4 of gitlib, with the main gitlib library already ported to the new structure. It uses a DSL instead of the MonadGit typeclass, making some code much simpler to reason about, and allowing backends to optimize better (for example, since CLI git accepts reference names for commit ids, there is no reason to split looking up a reference and then looking up a commit into two different commands).

[jwiegley]

It's happening on the v4 branch.

[deepfire]

@jwiegley, do you have any plans on releasing the v4 branch?

[jwiegley]

Unfortunately I have no current plans, because I simply lack the time to do it. Every need I have for gitlib is currently being satisfied with v3, work does not need gitlib, and I am buried under other projects both at work and personally. So, until there is a motivating factor, it's very hard to allocate the time.

[da-x]

If it helps anyone, I've made a workaround so that at least it does not throw an error, and instead returns the tagged commit. https://github.com/da-x/gitlib/commit/5b1ad46aaf091802b26828c68c625dac5a0e7444

[jwiegley]

v4 has been cancelled, due to the degree of change it would make to the API, but without much benefit. So I'm going to turn back to keeping v3 running.