repo fork: check that --org is not the empty string#3807
Conversation
|
Thank you! this code is not the easiest to maintain 😓 so I appreciate you diving into it. I'm actively working on cleaning up this code and its tests and this PR is a helpful step in that direction. |
|
Hi, thank you for the contribution, but we won't be merging this. The code looks okay, but this adds very specific ad-hoc validation to just the If we were to solve the problem of users passing invalid flag values (e.g. empty values for string flags that expect a non-empty value, which is most of them), I would much rather see a single solution that solves this across the board (for example, by using Cobra's hooks mechanism) rather than just for the |
|
@camillesf I'm sorry for making the decision on this prematurely. There was nothing wrong with your contribution; it's just that I had ideally wanted a solution that encompasses all flags and commands affected by this lack of validation. But of course, we have to start somewhere, and your changeset is a good start. 👍 |
mislav
left a comment
There was a problem hiding this comment.
This looks good to me! Note that the test file might not have conflicts due to recent changes to fork_test.go
As it is already being done for --remote-name, except in this case the default is the empty string.
2b3f7c1 to
568f4e4
Compare
|
That's great, thank you! I've rebased to resolve conflicts. Re: solving this at Cobra-level, I agree. Before doing it this way, I did take a look at cobra and pflags (which were unknown to me) to see if something built-in was available, but I didn't see anything. I'll actually take a look at hooks now, as you hinted—that's a useful pointer, thank you. |
Thanks for checking that. I remember also looking into this, but I don't think either Cobra nor pflag had any facilities for defining flag validation. Even so, I think it could be possible to add validation using Cobra's command hooks. For example, a global pre-run hook could iterate over all value flags that are marked "changed" (i.e. they were explicitly included in the invocation) but whose value is blank or whitespace-only. Then it can report those as an argument processing error. An additional thing left to solve would be how would we explicitly mark some flags as allowing blank values? For example, we will want to allow any value, including blank, for a |
I came across this while looking at #2722. I think that issue could keep its help wanted tag, but—and forgive me—after staring at this code for so long, I'm not sure it is that of a ‘good first issue’ anymore! (Or perhaps it's just me.)
I also realize the second commit in this PR might get disputed (because “readability” is often, implicitly, “readability at which level/at which ability”)—I'm happy to see this merged with or without that commit. 🙂
Thank you for your work on gh!