-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor: Parse environment variables into arrays #338
Conversation
FYI: I removed the empty line at 120 that did not make sense anymore. Everything else is exactly as it is in #326. |
Great, that's exactly how I meant it. 👍 Looking at this change it's obvious what it does, so approved content-wise. One thing to improve, though: I would like to see the PR description in the commit message. Furthermore it should have a "Refactor: " prefix or something similar in the headline IMO. And just to be sure: this PR does not change any behavior, does it? It really is pure refactoring, right? |
And for completeness: I did a quick test with I also added a link to the original issue #324 above and removed the "won't merge" part, because we will actually merge this, we just wait until the review and rebase in #326 is finished. |
Forgit allows specifying git options in environment variables that are passed along to the individual git commands. We currently treat those as strings. This commit adds a _forgit_parse_array function and uses it to parse all such environment variables into arrays instead. This will allow us to get rid of deferred code, since we can pass the parsed arrays directly to the git commands and don't have to rely on eval.
Done
Yes, the behavior should be identical to what is was before.
I'm a bit confused by that. I thought we would close down this PR and merge the commit with #326 or are we talking about the same thing here? |
…o not spent time parsing arrays we never use
FYI: I will keep changes as commits around here to make the review process easier, but will squash everything from this PR together when I rebase #326. |
@sandr01d Great, thanks a lot!
Great, then this is approved from my side.
I just re-read our thread in the other PR and noticed that I obviously got you wrong when I said "Exactly." 🙈 Sorry for that. I imagine in the end we'll have something like this:
Of course we could just merge PR 4 and close the others when we're finished. But we can as well merge all PRs sequentially in the end, one after another, so that effectively each PR only contains its dedicated commit afterwards. We just don't merge every PR right away, but instead wait until we have all PRs ready, so that we don't have to test each one individually. That being said, I think in this case we actually could merge right away if we're sure that it does not change the behavior. What do you think? |
Gotcha now.
I think I would prefer to wait until we're done with the review process before we start merging anything. I don't see any benefit in merging it right away and #326 has seen way more testing by now, while the changes here are still pretty new. Also in case we decide to change an implementation detail in this PR further down the review process, not having this merged already will save us from additional rebasing. |
@cjappl I've implemented the changes you requested, do you approve aswell? |
Yep approved! Thanks.
…On Wed, Jan 31, 2024 at 10:36 AM, sandr01d ***@***.***(mailto:On Wed, Jan 31, 2024 at 10:36 AM, sandr01d <<a href=)> wrote:
***@***.***(https://github.com/cjappl) I've implemented the changes you requested, do you approve aswell?
—
Reply to this email directly, [view it on GitHub](#338 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ADMDXY3RY6VNGALRACCDSTLYRKFJPAVCNFSM6AAAAABCPWP5MSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJZG4YDMMJRGU).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Alright, that sounds reasonable! |
Changes have been merged with #326 |
Check list
Description
Forgit allows specifying git options in environment variables that are then passed along to the individual git commands. We currently treat those as strings. This PR adds a
_forgit_parse_array
function and uses it to parse all such environment variables into arrays instead.Rationale
This step is necessary to get rid of deferred code. Currently, the environment variables are space separated strings, which do get split by using
eval
. Parsing these variables into arrays allows us to get rid of theeval
usage further down the line. As a positive side effect, it avoids unintended globbing and word splitting.Type of change
Test environment
Note
This PR belongs to #324 and resulted from discussions in #326.