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
Add tool for importing webrev patches #32
Conversation
|
Webrevs
|
Thanks Jorn for you contribution! I just had time to take quick look at the code, but wanted to share some high-level thoughts before diving in deeper. I would suggest splitting this tool into two:
The motivation would be to two piggyback on already known git commands apply and fetch and try
Regarding the verbose naming of the tools, I actually intended for them to look like webrev subcommands
I would suggest slightly re-purposing this PR into becoming the PR for What do you think? |
Response inline...
Okay, so it would just be like
Oh yeah, good point!
Can't the
If were going with deriving more information from the webrev, I'd rather try to find it in the webrev body, we can possibly get:
I think some heuristic is good, but we should have a good fallback as well, since we're not guaranteed to find the wanted information. Using the webrev URL as a commit message seems like a good one!
Well, not all webrevs target the master branch, but I get your point. An easy way to sidestep this problem is to use the current HEAD as the parent (and whichever branch this might be).
Sounds good! Overall I think we can use several heuristics to create a
Okay, sounds great to me! (just having the usual case of new-contributor-syndrome, not trying to step on anyone's toes
Sounds good. Also, I wanted to ask what you want to do for tests? I noticed there are no other test in the FWIW, not all the tests pass on Windows currently, particularly some tests that rely on unix tools/path-separators, and quite a bit of the |
Yes,
I don't think so? But I haven't tried this idea However, the above will be a little fiddly, so it is probably best to just start with a warning if the index is dirty.
Good point! I would probably recommend a mix, since not everyone creates webrevs with
That sounds like a good start, please consider adding it to the
Haha, the only toes you can step on are mine and Robin's, and we step on each other's toes all the time, so they are fairly hardened by now
I general we try to put as much logic as possible into the various libraries and then test the libraries (since they are easier to unit test than the CLI tools). The CLI tools are primarily meant to be small programs "gluing" together a few libraries and therefore I have resorted to manual testing. Some of the CLI tools (the ones not requiring a network connection) should be fairly easy to test though, so feel free to add tests to the
Sorry to hear that the tests aren't passing on Windows, they should pass (we are running them on Windows from time to time). We have something in the works regarding CI, but we need a little more time to work on it, so please stay tuned for that. |
Updated this to be a sub command of I made a utility called using
Pretty much all the other functionality is the same, but I've removed the options from the apply command. It now only takes a url as input. |
- Add missing space between }else - Move initializing of path variable inside of if block
args/src/main/java/org/openjdk/skara/args/MultiCommandParser.java
Outdated
Show resolved
Hide resolved
args/src/main/java/org/openjdk/skara/args/MultiCommandParser.java
Outdated
Show resolved
Hide resolved
args/src/main/java/org/openjdk/skara/args/MultiCommandParser.java
Outdated
Show resolved
Hide resolved
Great work @JornVernee! Just a few tiny comments that you can fix before integrating
args/src/main/java/org/openjdk/skara/args/MultiCommandParser.java
Outdated
Show resolved
Hide resolved
webrev/src/main/java/org/openjdk/skara/webrev/WebrevMetaData.java
Outdated
Show resolved
Hide resolved
@JornVernee This change can now be integrated. The commit message will be:
Since the source branch of this PR was last updated there have been 9 commits pushed to the
Since there are no conflicts, your changes will automatically be rebased on top of the above commits when integrating. If you prefer to do this manually, please merge
|
/integrate |
As discussed on the mailing list: https://mail.openjdk.java.net/pipermail/skara-dev/2019-July/000176.html
This PR adds a tool for importing webrev
.patch
files, either from a webrev url or local file path into a repository.I've named the tool
wimport
as short forwebrev-import
(I thought the full name sounded a bit too much like a sub-command ofwebrev
). This will first checkout a new branch, then apply the patch, and then create a commit for the patch with the messageImported patch 'NAME'
, similar to what is done by mq. Afterwards a user can just delete the new branch when they're done with e.g. reviewing the webrev. Although, there is also an option to directly apply the webrev without creating a branch or commit.Currently the following options are supported:
Progress
Approvers