Re: Git: new feature suggestion

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 19, 2017, 19:16 UTC
Message-ID: <CA+55aFzGaxhRRHXUcfnUDcgyaAKy4jXLcKMXH8T61x8sxEJT+g@mail.gmail.com>
In-Reply-To: <991ef396-3fc3-27d6-283c-b8dffa10a7b7@synopsys.com>

On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:

Show 7 quoted lines

>
> 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