# Make patch-id more flexible? 3 messages from 2017-11-24 to 2017-11-30. Participants: Eugeniu Rosca, Junio C Hamano. Thread: https://gitlist.dev/t/47310 ## Eugeniu Rosca, 2017-11-24 07:33 Subject: Make patch-id more flexible? Message-ID: <20171124073327.GA15188@vmlxhi-102.adit-jv.com> URL: https://gitlist.dev/e/20171124073327.GA15188%40vmlxhi-102.adit-jv.com ``` Dear git Community, This is my first post to the git mailing list, so I would first like to express my gratitude to everyone involved in developing one of my favorite development tools. I will make my question short and concrete. My day to day job is doing Linux kernel integration, which also includes importing of out-of-tree kernel modules into the kernel tree. Our team extensively uses cherry picking for integration purpose, since most often merging work is simply not possible because of a different kernel base used by our suppliers. We don't rebase remote commits --onto our repository/branch, since (compared to `git cherry-pick -x`) `git rebase --onto` doesn't add source/origin information to commit description. The `(cherry picked from *)` line is extremely helpful in generating proper commit statistics on a given branch, which is interesting because of a high amount of commits coming from various non-vanilla remotes. Reviewing the cherry picked commits, we extensively rely on patch id comparison. We've developed scripts that extract the remote commit hash from the `(cherry picked from )` line in the commit description, in order to produce tables like below: Remote-commit-id Local-commit-id Patch-id-mismatch? No Yes --------------------------------- No This information helps the reviewer identify the non-clean picks, which are oftentimes (but not always) caused by manual conflict resolution, which we try to briefly document in square brackets above the `Signed-off-by` signature. We feel that documenting any manual conflict resolution is important, as it can be source of bugs if not done properly. Troubles begin when we import out-of-tree kernel modules in-tree (some suppliers delivery many of them). We use subtree cherry picking [1] for that. Because subtree strategy alters the file-names, there will always be a patch id mismatch between the origin commit and its pick. To overcome this, we are using alternatives to `git patch-id`, which ignore file-names. Here comes my actual question. Would it be conceptually fine to implement some `git patch-id` parameter, which would allow ignoring the file-names (or reducing those to their `basename`) before computing the patch id? Or would it break the concept of patch id (which shouldn't accept variations)? Thank you. Eugeniu. [1] git cherry-pick -x -s --no-merges --strategy=subtree -Xsubtree=drivers/staging/mymodule .. ``` ## Junio C Hamano, 2017-11-24 07:51 Subject: Re: Make patch-id more flexible? Message-ID: URL: https://gitlist.dev/e/xmqqlgiwm7x1.fsf%40gitster.mtv.corp.google.com In-Reply-To: <20171124073327.GA15188@vmlxhi-102.adit-jv.com> ``` Eugeniu Rosca writes: > file-names. Here comes my actual question. Would it be conceptually fine > to implement some `git patch-id` parameter, which would allow ignoring > the file-names (or reducing those to their `basename`) before computing > the patch id? Or would it break the concept of patch id (which shouldn't > accept variations)? My gut feeling is that a tool like that would be fine as long as it is local to your organization and is not called "git patch-id"; it may be useful in the situation you described, but as you mention above, it feels that it is differnt from what a patch-id is. ``` ## Eugeniu Rosca, 2017-11-30 10:35 Subject: Re: Make patch-id more flexible? Message-ID: <20171130103539.GA19237@vmlxhi-102.adit-jv.com> URL: https://gitlist.dev/e/20171130103539.GA19237%40vmlxhi-102.adit-jv.com In-Reply-To: ``` Hello Junio, > > file-names. Here comes my actual question. Would it be conceptually fine > > to implement some `git patch-id` parameter, which would allow ignoring > > the file-names (or reducing those to their `basename`) before computing > > the patch id? Or would it break the concept of patch id (which shouldn't > > accept variations)? > > My gut feeling is that a tool like that would be fine as long as it > is local to your organization and is not called "git patch-id"; it > may be useful in the situation you described, but as you mention > above, it feels that it is differnt from what a patch-id is. > Thank you very much for your feedback. That's exactly I was looking for. A clear statement from the maintainer. We will live then with a custom tool that acts like `git patch-id`, just strips the patches from file-names before computing the hash. Best regards, Eugeniu. ```