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

[Jeff Cody <jcody@redhat.com>]

On Tue, Nov 10, 2015 at 04:49:12AM +0100, Max Reitz wrote:
> 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.
> 
> Max
> 

Yeah, it is a limitation of the "match-by-title" method.  I suppose we
could add a couple different matching "engines", some of which may
work better for some scenarios rather than others (for instance,
looking for cherry-pick lines, etc..).  Maybe even go so far as try
and match patches based on similar content.