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 <commit-id>)` line in the commit description, in order to produce tables like below:
Remote-commit-id Local-commit-id Patch-id-mismatch? <rem-commit-id-1> <loc-commit-id-1> No <rem-commit-id-2> <loc-commit-id-2> Yes --------------------------------- <rem-commit-id-N> <loc-commit-id-N> 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 <commit-X>..<commit-Y>
