Add west patch subcommand #59998
Add west patch subcommand #59998
Conversation
`west patch`: E.g. this allows to stay on a mainline zephyr revision, while maintaining patch files in the project SDK. This can solve the "two pace" problem for long zephyr release cycles versus immediate project need, without maintaining a fork. Signed-off-by: Manoel Brunnen <[email protected]>
So when people post issues and give a commit ID for the version with the issue, this is now likely to be invalid because they could have applied random patches? Not sure I see the point in this |
|
Which would be also true when maintaining a project fork. |
|
If you're working on a fork, why would you need this when you can branch and push as much as you want? |
|
In our projects we need our upstreamed patches, but we want to stay on a release revision for zephyr and possibly other modules. So we keep patch files in our SDK and apply them with west patch. We keep them until these patches have been integrated in a release. |
There was a problem hiding this comment.
Hi there. Thanks for the proposal. I am nacking this because:
- This PR and command belong in the west repo as a built-in command, not an extension one
- This has been discussed here: Add git-patch feature in west update west#596
Sorry for the misunderstanding, maintaining forks is exactly what we try to avoid. |
There was a problem hiding this comment.
Sorry for the misunderstanding, maintaining forks is exactly what we try to avoid.
But you are maintaining a fork, albeit one that is worse than if you just forked the repository and hosted that instead whereby you'd be able to do things like compare git commit IDs to see what changes were introduced or be able to rebase, for that reason I am NACK'ing this.
If you want to use this, you should have it as part of your own custom west commands in, let's say, a forked zephyr repository
|
I am using this, in our SDK module. |
west patch: E.g. this allows to stay on a mainline zephyr revision, whilemaintaining patch files in the project SDK. This can solve the "two pace"
problem for long zephyr release cycles versus immediate project need,
without maintaining a fork.