Carthage doesn't read latest commit in local repository

[sstadelman]

Basically a general case for the corner-case https://github.com/Carthage/Carthage/issues/968. Carthage is not reading the latest commit in a local git repository, and instead is repeatedly checking-out the commit which was available when first pulled. I see this happening even without the _relative paths_ condition.

I've tried deleting the Carthage.resolved, and deleting the entire Carthage folder in the consumer project, with no effect.

I've tried varying the branch tracking tag as the following, also with no effect:

git "file:///Users/i826181/xCodeProjects/myframework" "master"
git "file:///Users/i826181/xCodeProjects/myframework" "HEAD"
git "file:///Users/i826181/xCodeProjects/myframework" "head"

It seems that the only workaround is to delete the Carthage cache after each commit https://github.com/Carthage/Carthage/issues/968#issuecomment-197360787.

[dominik-hadl]

I have the same issue with remote repositories located on Github, Gitlab and as mentioned above also with local repositories. This started happening in Carthage 0.15 or 0.15.1.

Cleaning the cache always fixes it, but I now have to do that every time before I run carthage update.

[mdiep]

You should also be able to work around this bug using carthage fetch. I think the issue you're seeing here is specific to dependencies that are specified using branches.

[zwang]

@mdiep thanks for the work around. It works for me(at least for remote github repo, first do carthage fetch https://github.com/zwang/ambly, then carthage update get the latest commit ). Have been trying to figure this out for hours in the last two days.

Before this work around, I usually go to do something else and try to do carthage update later. Sometimes it works after half an hour, sometimes it does not after 10 hours...

[KoCMoHaBTa]

I also hit this issue when trying to update github repository that has not tags in it

[justinmakaila]

@KoCMoHaBTa In that instance, you should specify a branch or a commit

[KoCMoHaBTa]

@justinmakaila I'm specifying the master branch in the Cartfile. However once the repository is cloned, the cache is never updated, so running carthage update fetches the commit that was initially used to resolve the dependency. Basically when a new commit is introduced in the repository for the master branch - it never get pulled. Deleting the cache is working around the issue, because it force the repository to be cloned again.

[mdiep]

You can also run git fetch url-to-repository To force Carthage to update.

[mdiep]

Err… I meant carthage fetch. ☺️

[robertjpayne]

Was this published yet? Seems like it's still broken in 0.15.2.

[mdiep]

Not yet. It'll be in the next release, but we're waiting for Xcode 7.3 support before releasing.

[fulldecent]

FYI, carthage fetch ../SimpleMultiplier still gets the old commit for me.

[0xml]

Had the same problem with local repository, what solved it is clearing cache rm -rf ~/Library/Caches/org.carthage.CarthageKit

[stephenyao]

I just tried:

git "file:///project/directory" "HEAD"

and it seems to always point to a specific commit on master, even if i'm on a different branch.

Tried removing the branch and all but still can't seem to get it to checkout tip of current branch.

[mdiep]

Carthage doesn't look at the working directory, so HEAD won't work.

[stephenyao]

Thanks for your reply. Do you know if there is anyway to achieve the outcome I wanted?

[mdiep]

I don't think that there is.

[markpokornycos]

I hit this issue today on v0.26.2. I had to clear the cache as @pawelropa suggested...tried branch, tag, & commit hash with no avail. Further, Carthage would fetch a commit that doesn't even exist in either the local repo or the remote.
👍 for @pawelropa
Either this is a regression or it wasn't fixed. In either case it feels like this should be re-opened.

[sprynmr]

Still seeing this v0.29, no workarounds seem to be helping.

[sprynmr]

Disregard. Wasn't deleting the Cartfile.resolved file!

[ikesyo]

There is a different issue for local repositories with relative paths: #968.