feenkcom
Switch Iceberg to CLI in the GT release image and in the development image
Apart from the risk of doing something new, which we should take IMHO, there are two main issues:
- (1) it would require git cli to be present where you want to use GT for git, but we could have a fallback/switchback to the old implementation if we detect git is missing
- (2) the current build will probably still use the old implementation as well, even though we now have a separate iceberg-git-cli repository meant to be loaded first, but this is untested
A next step could be to let all local built images switch by default or with an option.
A new tool, GitCliEnabler, was added to play with switching/reverting, on a per repository / all repositories level.
WARNING: do not do this when you have repositories with uncommitted modifications !
A new command line handler, GitCliEnablerCommandLineHandler for the option enablegitcli was added.
- This enables the git cli iceberg implementation and switches over the implementation of all existing repositories.
- This has no effect on the on disk git repositories themselves.
- A number of validations are run before starting, some assertions might fail.
- You need the git command line executable installed, accessible, configured and working.
- Running without --save can be considered a dry run.
Note: to also save the image after enabling git cli, the following command should be used:
./GlamorousToolkit.app/Contents/MacOS/GlamorousToolkit-cli --interactive GlamorousToolkit.image enablegitcli --save
The --interactive flag is needed because the regular build image has already been opened as such.
Another way to experiment with automatically enabling git cli is through a startup file.
With startup.st in your current directory and the following contents:
IceGitCliPlatform current signCommits: true.
GitCliEnabler new switchAll.
('{1} startup.st loaded & executed successfully' format: { ZTimestamp now }) crTrace.
repositories will be switched when necessary. Once you save your image, this becomes a no op. The above code also enabled commit signing which is optional.
@svenvc Is GitCliEnabler new switchAll. something I should be adding to my startup scripts before running metacello loads?
If you are comfortable running/using the new git CLI implementation, then yes you can.
It will switch over all existing repositories and make it the default going forward (when you do new Metacello loads).
Does this unlock any features/code/views/tools/etc that I'd be missing otherwise? Does feenk need people to beta test anything? Will git cli implementation become the default at some point soon? Just not sure what this would do, I just stumbled upon this ticket.
not sure what this would do
NB the new implementation requires storing GH credentials in plain text in the image, meaning they will be saved to disk if the image is saved. That was a deal breaker for me, but not for everyone.
Does this unlock any features/code/views/tools/etc that I'd be missing otherwise? Does feenk need people to beta test anything? Will git cli implementation become the default at some point soon? Just not sure what this would do, I just stumbled upon this ticket.
I wrote 2 more documentation pages linked from the main README in https://github.com/feenkcom/iceberg-git-cli that explain the rationale behind the switch to git CLI and the user level features that it adds.
- https://github.com/feenkcom/iceberg-git-cli/blob/main/doc/why-git-cli.md
- https://github.com/feenkcom/iceberg-git-cli/blob/main/doc/git-cli-features.md
not sure what this would do
NB the new implementation requires storing GH credentials in plain text in the image, meaning they will be saved to disk if the image is saved. That was a deal breaker for me, but not for everyone.
This is incorrect.
Git CLI does not do anything for authentication/authorisation in git. It assumes you have set up things for git on the command line to just work unattended, i.e. without any password prompts. This can be done in several ways, the most common one being using ssh keys and ssh-agent.
That being said, it is true that fork and createPullRequest methods on GtGitRepository, which interact with GitHub through its REST API, need a GitHub personal access token. The helper GtGitHubTokenHolder implements several ways to access such a token, one of them being reading the token from a file each time it is needed, thus never storing it in the image.
As we also discussed before, you do not need to use the fork and createPullRequest operations in GT. It is indeed also possible to do both manually in the GitHub web interface.
@seandenigris sounds like you may want to run GtGitHubTokenHolder readTokenEachTimeFrom: '/some/path/to/token.file' at startup, I will plan to do that. Every time I create a PR and follow the GT book page on that I forget that step and get a debugger.
This is incorrect. As we also discussed before, you do not need to use the fork and createPullRequest operations in GT. It is indeed also possible to do both manually in the GitHub web interface.
Thanks for the clarification. So it seems like all previously existing functionality is available without storing a token in-image. And if one doesn't mind about that, the benefit is that we can also now fork and create PR. If so, sounds good.