i'm trying to add a KMP repo to my iOS project usi...

# touchlab-tools

[Darrel Roof]

i'm trying to add a KMP repo to my iOS project using gitportal, i did the "`gitportal setup library https://reponame.git -t 1.0.0`" step to add my KMP repo to my iOS native project and that worked however when i try to pull down a specific branch from the KMP repo using "`gitportal pull -b branchname`" i get a InternalCommitNotInRepo, can you provide some info on what that error means and if there's a step i'm missing before trying to pull in a branch from the KMP repo, thanks?

[kpgalligan]

OK. To preface, apologies. The whole tool went through a few "phases". The "leaving the ocean" phase was "git subrepo > Kotlin". Lots of smart ideas, in one huge bash script. Phase 2 was, "add the things we need that subrepo didn't do". Then "OMG, subrepo is a mess, refactor (with lots of test coverage)". The most recent phase was "exception/error management and reporting is all over the place".
That particular sealed-class-derived error, InternalCommitNotInRepo, should have also included the message:
>

"Local repository does not contain $configCommitFromHistory. Try force pull."

What that should actually say is:
>

"Remote repository target does not contain $configCommitFromHistory, which is in your current remote target. Try force pull."

Or, perhaps:
> Tag 1.0.0 has commits that branch branchname does not. That may result in unexpected issues if those commits are expected in your local code. To override this safety check, run pull with force enabled.
What it's saying is, you're trying to pull from a target that doesn't contain everything that's in your current library. Specifically, tag 1.0.0 has a commit that branch branchname does not.
The logic is technically more complicated than that, but in the "unidirectional" mode, that extra complication shouldn't matter.
For unidirectional, I've gone back and forth on this. Assuming you're following "the rule", which is when the local folder points at a tag, you don't locally change the KMP (and certainly don't commit a local change), a pull from a branch that throws this error shouldn't be a problem. There's no work that would have been lost. Even if there was, it's in the git history, so it's not lost.

TL;DR, if you haven't changed the local code, just add the force tag (-f). If you have changed the local code:
1. I'd love to know the specifics of how you arrived at this error
2. It'll be in git history, so worst case, just branch off the commit before the force pull. GitPortal relies on git, very much including not "changing history"
If the branch does indeed have everything the tag had (commit-wise), and you got this error, well, again, I'd love some details, happy to chat directly. GitPortal's bidirectional mode added quite a bit of complexity, and was built after and on top of unidirectional, so there may be edge cases that tests didn't cover.
Besides the bad error message, obviously.

[Darrel Roof]

thanks @kpgalligan adding the force tag worked, i was able to checkout the branch i needed, as far as how i arrived at the error all i did was i did a complete reset to master on my iOS branch so that it had no changes in my local repo and then i just did the "`gitportal setup library https://reponame.git -t 1.0.0`" to pull down the KMP branch from the 1.0.0 tag and the next step "`gitportal pull -b branchname`" without making any changes inbetween and the branch is based off the 1.0.0 tagged branch so it should have everything from there. I repeated these steps a couple of times and got the same results each time

I didn't commit the the 1.0.0 changes to my local iOS repo before trying to pull the KMP branch, do i need to do that first?

[kpgalligan]

I didn't commit the the 1.0.0 changes to my local iOS repo before trying to pull the KMP branch, do i need to do that first?

You should not. GP commits the changes it's operation performs (another convention from git subrepo that may be reviewed, as it's a bit heavy-handed)
I'll try to set up a repro locally of what you did. If the code is "template level", as in nothing specific to your app, if possible, add me, or send me a zip of the exported KMP repo. https://stackoverflow.com/a/26552740/227313. I zip of a clone would probably be fine, but a zip of the full repo isn't that hard, and may contain something interesting.
I'll still try a repro locally. This is probably something simple. Sort of a git "one off" error because the code is expecting a history with multiple commits (something like that)

[kpgalligan]

I just did a basic version of your steps and didn't have the same issue. I want to think about other possible issues that would cause what you saw, but obviously a repro would help a lot.

[Darrel Roof]

unfortunately this is proprietary code that i cannot share but i am reaching out to a others on my team to see if they can reproduce the problem, i tried these steps in a different project folder and got the same results so it might just be something with my gitportal state? I'll let you know if others get the same results. thanks

[kpgalligan]

If the KMP project history is relatively clean/short, could you maybe do this? There's probably a more elegant way to accomplish what I want in git, but...

git rev-list 1.0.0..branchname
git rev-list branchname..1.0.0

The first should have results. The second should, I believe, be empty, although that's from my mental model of how git evaluates that and limited "just now" testing, but functionally, that's what the thrown error is looking at.

[Darrel Roof]

thanks @kpgalligan that did help us identify the issue, looks like we did have one commit that was in the tagged commit but not in the branch itself and that was the tagged commit itself (along with another change) , apparently it never got merged to main which is what the branch was based off of. Thanks for your help and i apologize for confusion

[kpgalligan]

Glad you figured it out. That helped me. The error message needs to be far better, and now there's a good debug step. It would be straightforward to actually print that out in the error, but probably include the commit and at least the title. Commit shas are, obviously, not very informative on their own.