Closed petertseng closed 8 years ago
I have a few questions and suspect this will not be merged in its current state (and maybe not even at all), but I needed to submit the PR so that we could at least get some discussion around the code.
1) Bikeshed on the flag name? no-dry-run
, etc.
2) This is my workflow, but what if it doesn't fit everyone else's workflow? What if other people would prefer to just do it, without a confirmation or the hassle of passing -yes
? Well, worse comes to worse I'll keep this on my branch and I'll use it personally, even if not everyone uses it.
3) Probably output at the end "That was a dry run. Pass -yes
to actually submit."
(By the way the Travis failure... is because Travis thinks this is a Ruby project because of no .travis.yml)
example
$ blazon -file issue.txt -exercise sum-of-multiples
Would submit:
Test issue from blazon
This is the issue body. It *can* contain Markdown, if you really **want** it to.
Would submit to clojure
Would submit to cpp
Would submit to csharp
Would submit to ecmascript
Would submit to elixir
Would submit to erlang
Would submit to fsharp
Would submit to go
Would submit to haskell
Would submit to javascript
Would submit to lfe
Would submit to lua
Would submit to perl5
Would submit to python
Would submit to ruby
Would submit to swift
Yeah, I think a dry-run option would be excellent.
I don't have any strong feelings about the name of the flag; -yes
seems as good as anything else (-force
?), and better than the klunky -no-dry-run
.
I'd like to tweak the output, to remove a few of the "would submit"s:
$ blazon -file issue.txt -exercise sum-of-multiples
Title:
Test issue from blazon
Body:
This is the issue body. It *can* contain Markdown, if you really **want** it to.
This issue would be submitted to the following tracks:
- clojure
- cpp
- csharp
- ecmascript
- elixir
- erlang
- fsharp
- go
- haskell
- javascript
- lfe
- lua
- perl5
- python
- ruby
- swift
To submit, rerun the command with the -yes flag.
Seems good. I just took that verbatim.
Also changed flag description to be more informative.
And about force
, I would say I chose not to use it because it sems to have slightly different semantics. If we take git push
as an example, force
has the semantics of "I would usually perform this operation. But due to current circumstances, it's unsafe. Please confirm". With blazon
, yes
is more like "I'll never perform this operation unless you explicitly tell me to", regardless of circumstances.
Yeah, agreed. yes
has better semantics here.
Running without the 'yes' flag simply shows you the issue that would be submitted, and the list of tracks to which it would be submitted.
My usual workflow is to run without the 'yes' flag, make sure the list of tracks looks sane, and then run with the 'yes' flag.