https://rancher.com/ logo
Join Slack
Powered by
<@U0200LMSGAK>: I'm thinking about the right strat...
# rancher-desktop
q
@proud-jewelry-46860: I'm thinking about the right strategy for git username/email...
p
Ah, you wanted them as fallback instead of override? (Unrelated: TIL: --config-env)
q
i think so...
it's mostly because by default git runners default to having stupid identities
p
I was asking because you can probably get away with 
git -c user.name=$(git config user.name || echo "check-spelling-bot") -c user.email… commit
or something dumb like that
q
hmm
the 
-c
stuff has historically given me a headache
p
Oh, I guess the new way is 
get config get --default=check-spelling-bot user.name
q
i think i really do want to honor an env var if it's set, and i think this would do the wrong thing
i mean, sure, people could run 
git config --global ...
or whatever, but i'd rather let them do an 
env: ...
for my step
p
Ah, true, because 
user.name
isn't the same as `GIT_AUTHOR_NAME`…
q
especially since if they're using 
with:
checkout: 1
they can't use 
git config ...
because the repo doesn't exist yet
the interaction between GIT_AUTHOR+GIT_COMMITTER is stupid
p
Yeah, the configuration there is definitely over-complicated
q
i'm definitely not confident that what i have is ideal and am certainly open to alternatives, but i can assure you that this stuff has consistently given me headaches for years
p
Anyway, fun thing: my understand is that the actual precedence is 
$GIT_AUTHOR_NAME
, 
author.name
, 
user.name
, 
$USER
. See https://git-scm.com/docs/git#_git_commits and https://git-scm.com/docs/git-config#Documentation/git-config.txt-username
q
hmm
p
Anyway, your commit solve my immediate problem (because 
user.name
and 
user.email
is set, so everything gets skipped), just not sure it does what you intended 🙂
q
so what would i actually want to do?
i'm starting to think that maybe just doing the 
-c
thing you're suggesting would be correct
i'd definitely prefer fewer lines of code, and the -c form is definitely more concise
p
Hmm, and it has the advantage that the environment variables still override (because 
-c
is a config). But now it should be 
-c user.name=$(git config get --default=check-spelling-bot user.name)
q
i'm actually not sure i want just that
if someone set only one of user.name or user.email, do i really want to fill in check-spelling-bot for only the other?
that feels odd
f
I'm probably going to regret jumping in here, but why do you need to override the user setting at all? I can see a GitHub action overriding it, but when you run a tool locally, it should not use a bot identity.
q
there are a couple of different behaviors that check-spelling does, in one, it kinda wants to take credit for its own commit
so that you can ignore it when you're looking for commits you made
and if you want to take credit, it assumes you'd squash it into something else
i think i more recently made a thing where it would show you the commit you could make where you'd be crediting the bot w/ the commit
f
idk, shouldn't that be an option you explicitly specify, that is independent of the git config?
q
i think that's the code that's tripping up here
i think i might just want to use 
-c ...
unconditionally, and if someone uses the env vars, they win
thinking about it requires more brain cells than i can allocate this afternoon 😞
👍 1
i'll review the code and reconsider. I think that 
-c ...
for both is probably the right thing
(Getting the 
-c
syntax right was also not fun...)
Open in Slack
PreviousNext
Powered by