Definitely getting this issue too. Just using the standard checkout step. It usually goes away if we rebase and force push or amend the commit and force push.
I feel that it might be related to the Update Branch feature on Github but, haven’t confirmed that.
Hitting this issue myself now. I don’t quite understand git’s object system, but on both a failed build server I ssh’d into and a fresh clone my local machine I get:
$ ls .git/objects
info pack
So it seems no objects exist? Well, there are definitely objects, git rev-list --objects --all returns lots, but git rev-list --objects --all | grep $CIRCLE_SHA1 returns nothing. (And for the record $CIRCLE_SHA is the same hash value from the fatal: Could not parse object [...] error.)
I’m having this issue as well. I’ve narrowed it down to using multiple slashes in my branch name. e.g. da/my-bug-fix works but da/bug-21/my-bug-fix does not.
Related: Branch names with multiple slashes breaks checkout step during deploy
Do any employees regular this forum? The past few bugs I looked at have no feedback from Circle employees. This seems unacceptable…
p.s. not complaining to you, just wondering what the deal is. 
Bump #can’twork
@danny-andrews-snap @Did you remove the slashes from your branches to workaround this?
@Kevmo92 Does your workflow involve force-pushing? I wonder if you could outline what your specific workflow looks like - if you can produce a reproducible example, I expect CircleCI will bite your arm off. 
@halfer I’ve seen this a few times today, both in projects that don’t use workflows.
Our branches do have a forward slash in the branch name, but we’ve only seen this pop up in the past 24 hours.
It’s not reproducible though. The only way to get around it is to rebuild without cache and hope that circleci is able to actually checkout the repo.
I’m opening a ticket up with their support team ¯\_(ツ)_/¯
Yes, sorry - I didn’t mean a CircleCI Workflow; I meant your general manner of using Git/Circle/branches/PRs etc. Perhaps there is some common behaviour that connects all of these cases.
We’re a salesforce shop, so our workflow is generally:
I wonder if replacing the checkout step with a script that runs the same circleci logic would work any better 
Possibly, and it is worth noting that checkout is indeed an optional step. You can do your own, based on the env vars passed to the VM.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
In case anyone runs into this again, I find https://codewords.recurse.com/issues/three/unpacking-git-packfiles helpful.
Started hitting this today too when re-running a build – the Circle checkout step would fail. Pushing a new commit indeed fixes it.
I can confirm this bug.
It happens after hash being deleted (amend, squash, rebase, etc…).
remote: Counting objects: 575, done.
remote: Compressing objects: 100% (386/386), done.
remote: Total 575 (delta 324), reused 320 (delta 174)
Receiving objects: 100% (575/575), 103.77 KiB | 1.24 MiB/s, done.
Resolving deltas: 100% (324/324), done.
Warning: Permanently added the RSA host key for IP address 'RE.DU.CT.ED' to the list of known hosts.
fatal: Could not parse object '67cd9105a6012f15d3511a7131f49b2b98fc6c6b'.
exit status 128