Thanks, I need to take a detailed look at your PRs this will take some time.

You're very welcome!

A small note to help with reading: treat it as a Secure Storage Storyboard, and go through it in this order:

• Program.cs
• ToSchemaHashTable.cs
• ToAttributesHashTable.cs
• AccessToken.Tab.cs
• MicrosoftIdentity.Tab.cs

Don't work to much on this PR. First the Gir files must be updated on the main branch.

Afterwards this PR must be rebased again.

There probably don't need to be any unit tests. There are only tests that confirm that certain generator scenarios are supported. Current library specific tests are mostly legacy code.

If "Secret-1.gir" is available this PR should probably only include the absolute minimum to create and release the bindings.

I think if this is done there could already be a 0.7.0-Preview.1 release so users can benefit from GNOME SDK 48 and the new Secret-1 binding.

Where we put some helper methods needs to be figured out separately.

Done, rebased and updated.

If you now squash the last two commits and preserve the initial commit message we are all set! 🚀

Sorry for the inconvenience.

Done, and no worries at all! 🚀😊

Now you updated the gir-files git submodule (see files changed). I would recommend soft resetting the last commit and unstaging the change of the gir-files directory and committing and pushing again.

Perhaps make a backup branch beforehand to not loose your changes in case something goes wrong.

To ensure you are on the correct gir-files commit for the future you can check github: https://github.com/gircore/gir.core/tree/main/ext and just checkout the number at the end of the folder name (currently 5bce3d6).

Thanks for your work! It is great to have support for libsecret 🚀

One more explanation: I merged the PR despite that it was still not properly synchronized with main. In the beginning of the project I lost data because I merged a PR that was missing commits. This is why I enabled this rule and GitHub was still complaining for your PR. As there was no overlap with the missing commit it was fine to merge.

I would recommend making you more familiar with git so you have full control over your version history even if submodules are involved.

@czirok I have another idea what could be the root cause of the issue: You are working on a fork of GirCore.
So the main branch of your fork must first be updated to match the main branch of GirCore before rebasing your own feature branch on the main branch of your fork.

You can do this either via the GitHub homepage directly or you need to handle different git origins and do it manually.