[OE-core] [devtool] Incrementation of patch number when using devtool update-recipe

[Piotr Walczak]

Hi,

Firstly I would like to say hello and thanks for devtool app, it's a killer
feature which improves working with temporary sources a lot!

My question is related to following scenario:
I use the devtool (from poky 2.0.1) to modify sources for specific package
and then to generate patch, the work flow* is:

$ devtool modify <recipe_name> <ext_srcs_path>
$ [performing modifications in sources]
$ git commit -m "<patch_name>"
$ devtool update-recipe <recipe-name> -m patch -n -a <path_to_layer>
$ devtool reset

Let's assume that during one 'modify' session I've committed two patches,
the output is:

├── <package>
│ ├── 0001-first-change.patch
│ ├── 0002-second-change.patch
├── recipe_git.bb
└── recipe_git.bbappend

At this moment everything works as expected.
Then I push the changes to remote server (code changes to separate upstream
and patches to meta-layer repo).
When I need to add another patch, I start the same procedure:

$ devtool modify <recipe_name> <ext_srcs_path>
$ [src changes]
$ git commit -m "<patch_name>"
$ devtool update-recipe <recipe-name> -m patch -n -a <path_to_layer>

The patch is generated and located in the same place as previous patches,
bbappend is updated, everything is fine. The only problem is that during
this session of 'devtool modify', the patch is named again as
0001-<patch_name>, as a result the output is:

├── <package>
│  ├── 0001-first-change.patch
│  ├── 0002-second-change.patch
│  ├── 0001-third-change.patch
├── recipe_git.bb
└── recipe_git.bbappend

It doesn't influence the output image, patches are valid, only the version
number is confusing.
How can I avoid that and generate patch with increased version (0003 in
this case)?

* such a work flow is required due to some constraints (organization
policy) as I currently don't have access to repository from which this
package is being fetched.

Best regards,
Piotr.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160426/d7e8b7d3/attachment-0002.html>