NACK: [trusty/lts-backport-xenial][PATCH v2 0/1] update-from-*-master: add parameter to change source commit
Stefan Bader
stefan.bader at canonical.com
Fri Aug 18 14:06:24 UTC 2017
On 18.08.2017 15:41, Kleber Souza wrote:
> On 08/18/17 15:11, Stefan Bader wrote:
>> On 16.08.2017 18:15, Kleber Sacilotto de Souza wrote:
>>> The following patch change the 'update-from-*-master' script to
>>> accept a '-c' flag which will override the default 'master-next'
>>> branch and allow a rebase on top of any commit-ish, and a '-t'
>>> flag that will skip the search for the most recent closing
>>> commit, allowing to rebase even on top of an unclosed version.
>>>
>>> This is particularly useful along with the '-r' flag, which
>>> allows the user to provide a local tree which can be used to
>>> prepare a backport before the public tree is updated.
>>>
>>> I'm seding only one patch for now for discussion, if it is an
>>> acceptable solution I will send the other ones later (for
>>> precise/lts-trusty, xenial/hwe and xenial/hwe-edge).
>>>
>>> v2:
>>> - Changed '-b' to '-c' to make it clear that any commit-ish name
>>> is accepted.
>>> - Added the '-t' flag to split the functionality.
>>> - Renamed 'BRANCH' to 'COMMIT'.
>>>
>>> Kleber Sacilotto de Souza (1):
>>> UBUNTU: [Packaging] update-from-*-master: add parameter to change
>>> source commit
>>>
>>> debian.xenial/etc/update-from-xenial-master | 39 ++++++++++++++++++-----------
>>> 1 file changed, 24 insertions(+), 15 deletions(-)
>>>
>> You can already do that by using _SOURCE_RELEASE_BRANCH
>>
>> Like:
>>
>> _SOURCE_RELEASE_BRANCH=mybranch ./debian.xenial/etc/update-from-xenial-master \
>> [ -r <local git tree> ]
>>
>
> The idea was to have an easier and more flexible way to do the rebase on
> an arbitrary tree (not that setting an environment variable is hard, but
> one needs to look at the script to figure that out).
Of course, and I have to do that every time. :) Ok, guess I did not get the
intention as I do not see that lookup as a real issue. One thing that also made
me feel uneasy about this was that it sounded too flexible. Not being able to
specify anything but a different branch name at least made me feel some pain
when I messed up anything with the tagging and from then on I would learn.
To be able to specify a commit style id felt (must not be the truth) like one
could easily cover up for those mistakes.
-Stefan
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20170818/6f2f841c/attachment.sig>
More information about the kernel-team
mailing list