Make patch-id more flexible?

Make patch-id more flexible?

[Eugeniu Rosca]

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>

Re: Make patch-id more flexible?

[Junio C Hamano]

Eugeniu Rosca <erosca@de.adit-jv.com> 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.

Re: Make patch-id more flexible?

[Eugeniu Rosca]

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.