* Make patch-id more flexible?
@ 2017-11-24 7:33 Eugeniu Rosca
2017-11-24 7:51 ` Junio C Hamano
0 siblings, 1 reply; 3+ messages in thread
From: Eugeniu Rosca @ 2017-11-24 7:33 UTC (permalink / raw)
To: git; +Cc: erosca
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>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Make patch-id more flexible?
2017-11-24 7:33 Make patch-id more flexible? Eugeniu Rosca
@ 2017-11-24 7:51 ` Junio C Hamano
2017-11-30 10:35 ` Eugeniu Rosca
0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2017-11-24 7:51 UTC (permalink / raw)
To: Eugeniu Rosca; +Cc: git
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Make patch-id more flexible?
2017-11-24 7:51 ` Junio C Hamano
@ 2017-11-30 10:35 ` Eugeniu Rosca
0 siblings, 0 replies; 3+ messages in thread
From: Eugeniu Rosca @ 2017-11-30 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-11-30 10:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-24 7:33 Make patch-id more flexible? Eugeniu Rosca
2017-11-24 7:51 ` Junio C Hamano
2017-11-30 10:35 ` Eugeniu Rosca
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).