Suggestions for improved usage

[tfoote]

Please add to the readme usage documentation. I found some executables by tab completing. However there should be documentation of the top level commands.

Here's some more features for better usability.

I ran with --dry-run and it finished w/o filing a PR, but didn't tell me where the output was. (I found it in /tmp by listing latest changes.) If it generates a temp-dir it should clean it up or at least tell you to clean up.

It would be great to parameterize the output directory to allow reuse of a preexisting local checkout of the repo so you don't have to refetch it if you already have a clone.

Following that if you run with --dry-run and a non-temp directory an option --pr-only would be helpful after reviewing the result.

And adding arguments for the upstream repo will be important for anyone who wants to fork etc. Also supporting a config file would be good for this too.

[allenh1]

I ran with --dry-run and it finished w/o filing a PR, but didn't tell me where the output was. (I found it in /tmp by listing latest changes.) If it generates a temp-dir it should clean it up or at least tell you to clean up.

That's very true. I'll add a message to the end of the dry run that gives the temp directory and says that they should clean it up or run again with --pr-only.

It would be great to parameterize the output directory to allow reuse of a preexisting local checkout of the repo so you don't have to refetch it if you already have a clone.

I think @Alessandro-Barbieri suggested something similar in #32. I'll add that to the list.

Also supporting a config file would be good for this too.

Sounds good to me. Things like overlay-repo, overlay-branch, ros-distro, are some possible settings I'm thinking of. Got any more for me?

[allenh1]

@tfoote I think this is resolved -- can this be closed?

[tfoote]

It's fixed for ebuilds. Do you want to track adding open embedded separately?

[tfoote]

Actually reading it through again. A high level of what the process does and what expected inputs and outputs are would be very helpful.

[allenh1]

And adding arguments for the upstream repo will be important for anyone who wants to fork etc. Also supporting a config file would be good for this too.

@tfoote I think this is the only residual complaint for this issue, right? Just going through the open issues. I also have some of these changes to replicate for open embedded.

[tfoote]

yeah, that new argument should be kept in mind but things are much better now.