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.
