[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v2 0/8] blockdev: Further BlockBackend work

From: Max Reitz
Subject: Re: [Qemu-block] [PATCH v2 0/8] blockdev: Further BlockBackend work
Date: Tue, 10 Nov 2015 04:49:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 10.11.2015 04:45, Eric Blake wrote:
> [side question]
> On 11/09/2015 08:27 PM, Max Reitz wrote:
>> Overall, this series adds more uses for BlockBackends and makes the code
>> follow the "reference theory" more closely, in that any BlockBackend
>> created (through -drive or blockdev-add) has a reference count of 1, and
>> that reference should be held by the monitor. This is reflected here by
>> introducing an explicit list of monitor-owned BlockBackends, which in
>> turn allows us to remove bdrv_states, and, perhaps most importantly,
>> blk_hide_on_behalf_of_do_drive_del().
>> Although I don't suppose anyone will care much, here's that
>> backport-diff against v1:
>> Key:
>> [----] : patches are identical
>> [####] : number of functional differences between upstream/downstream patch
>> [down] : patch is downstream-only
>> The flags [FC] indicate (F)unctional and (C)ontextual differences, 
>> respectively
>> 001/8:[----] [-C] 'block: Add blk_name_taken()'
>> 002/8:[----] [-C] 'block: Add blk_next_inserted()'
>> 003/8:[----] [-C] 'block: Add blk_commit_all() and 
>> blk_invalidate_cache_all()'
>> 004/8:[0073] [FC] 'block: Use BlockBackend more'
>> 005/8:[0004] [FC] 'blockdev: Add list of monitor-owned BlockBackends'
>> 006/8:[down] 'blockdev: Remove blk_hide_on_behalf_of_hmp_drive_del()'
>>       (renamed from "..._on_behalf_of_do_drive_del()")
> This is a nice note. Is there any way to make 'git backport-diff'
> automatically do this, or does it have to be done manually when renaming
> patches?

As far as I know, git backport-diff simply looks for matching patches
based on the title alone, so I don't think there's a way for it to
automatically figure out name changes.

I don't know of a way of telling it that a particular "downstream" patch
belongs to another particular "upstream" patch, though. So in general,
if I do want an accurate diff even for renamed patches (I did not here,
because v1 has been more than eight months ago), I just diff manually
and count the changes or temporarily rename the patch on the current
(new) branch.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]