Summary: | kdesrc-build could use a --patch argument to make testing a Phabricator patch super easy | ||
---|---|---|---|
Product: | [Developer tools] kdesrc-build | Reporter: | Nate Graham <nate> |
Component: | general | Assignee: | Michael Pyne <mpyne> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | wishlist | ||
Priority: | NOR | ||
Version: | Git | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Nate Graham
2018-12-24 19:30:57 UTC
That would be super rad! The way I'd envision doing this, I'd revert the patch after the build so the user would have to re-add the '--patch ...' stuff later. Is that OK? The reason I ask is that other ways to back-out the patch (such as git-clean) might also have the effect of wiping out *other* changes by accident, which is something I've always been paranoid about. Though if it would make more sense to keep the patch applied, we can use git-stash to keep unrelated changes first. Though that's also another point, I'm assuming that if there are other unrelated changes in the repo already, that kdesrc-build would keep those before applying the Phab patch. I'm tracking at https://invent.kde.org/kde/kdesrc-build/issues/4 but will keep the commentary going here for now. It wouldn't need to revert anything, since doing `arc patch D12345` creates a new branch called "arcpatch-D12345" so running kdesrc-build with --patch D12345 again would simply re-use that branch (or delete it and re-check it out), and omitting the --patch argument would switch back to the normal master branch. Not relevant anymore now that we have GitLab, and I suppose this is duplicative of https://invent.kde.org/sdk/kdesrc-build/-/issues/12. |