-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Feature request: make git_sitrep()
more digestible
#1714
Comments
Sure, sounds promising. |
I have hit a snag, on the intention of Incidentally, I have two emails set up in my git config: my work email is When I run
I traced this to a call to git_cfg_get("user.email", "global")
#> "ian.lyttle@<work>.com"
git_cfg_get("user.email", "local")
#> "ijlyttle@me.com"
git_cfg_get("user.email", "de_facto")
#> "ian.lyttle@<work>.com" "ijlyttle@me.com" Questions
Thanks! |
Yeah, I think so. I haven't touched this code in a long time, but, looking at it now, it sure looks wrong. I think that should be a separate PR and we should handle it first, then come back to this. I would also check if anything has changed favourably in the gert world since I wrote this. It doesn't feel great to be trying to emulate what git does here. I.e. I wish we had a way to pass the desire for the de facto setting to libgit2 and let it sort this out. But we might just have to keep doing this ourselves. |
I find
git_sitrep()
to be an immensely useful function. However, it does provide a lot of information at once.When you're just getting set up, it might be nice to get the status of just one part at a time. I think it could be interesting to provide some filtering options, e.g.:
Would you consider a PR where:
the function could look something like:
the output could use
cli::cli_h3()
headers?The text was updated successfully, but these errors were encountered: