Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libgit2: Cannot look up tag object #49

Open
nomeata opened this issue Jun 1, 2015 · 7 comments
Open

libgit2: Cannot look up tag object #49

nomeata opened this issue Jun 1, 2015 · 7 comments
Labels

Comments

@nomeata
Copy link

nomeata commented Jun 1, 2015

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?

nomeata added a commit to nomeata/gipeda that referenced this issue Jun 1, 2015
@jwiegley
Copy link
Owner

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

@jwiegley
Copy link
Owner

@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
Copy link
Owner

It's happening on the v4 branch.

nomeata added a commit to nomeata/gipeda that referenced this issue Jun 21, 2015
@deepfire
Copy link

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

@jwiegley
Copy link
Owner

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
Copy link
Contributor

da-x commented Jun 7, 2016

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. da-x@5b1ad46

@jwiegley
Copy link
Owner

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.

@jwiegley jwiegley added the bug label Feb 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants