On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>
> I am currently facing some challenges in one of Linux subsystems where a
> rename
> of a set of folders and files would be the perfect scenario for future
> development, but the suggestion is not accepted, not because it's not correct,
> but because it makes the maintainer life harder in backporting bug fixes and
> new
> features to older kernel versions and because it is not easy to follow the
> renamed file/folder history from the kernel.org history logs.
Honestly, that's less of a git issue, and more of a "patch will not
apply across versions" issue.
No amount of rename detection will ever fix that, simply because the
rename hadn't even _happened_ in the old versions that things get
backported to.
("git cherry-pick" can do a merge resolution and thus do "backwards"
renaming too, so tooling can definitely help, but it still ends up
meaning that even trivial patches are no longer the _same_ trivial
patch across versions).
So renaming things increases maintainer workloads in those situations
regardless of any tooling issues.
(You may also be referring to the mellanox mess, where this issue is
very much exacerbated by having different groups working on the same
thing, and maintainers having very much a "I will not take _anything_
from any of the groups that makes my life more complicated" model,
because those groups fucked up so much in the past).
In other words, quite often issues are about workflows rather than
tools. The networking layer probably has more of this, because David
actually does the backports himself, so he _really_ doesn't want to
complicate things.
Linus
