{"thread":{"id":"47310","subject":"Make patch-id more flexible?","startedAt":"2017-11-24T07:39:18Z","lastAt":"2017-11-30T10:36:01Z","messageCount":3,"participants":["Eugeniu Rosca","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"333421","messageId":"20171124073327.GA15188@vmlxhi-102.adit-jv.com","threadId":"47310","inReplyTo":null,"subject":"Make patch-id more flexible?","fromName":"Eugeniu Rosca","fromEmail":"erosca@de.adit-jv.com","sentAt":"2017-11-24T07:33:27Z","receivedAt":"2017-11-24T07:39:18Z","isPatch":false,"sender":{"key":"erosca@de.adit-jv.com","avatar":null},"body":"Dear git Community,\n\nThis is my first post to the git mailing list, so I would first like to\nexpress my gratitude to everyone involved in developing one of my\nfavorite development tools.\n\nI will make my question short and concrete. My day to day job is doing\nLinux kernel integration, which also includes importing of out-of-tree\nkernel modules into the kernel tree. Our team extensively uses cherry\npicking for integration purpose, since most often merging work is simply\nnot possible because of a different kernel base used by our suppliers.\nWe don't rebase remote commits --onto our repository/branch, since\n(compared to `git cherry-pick -x`) `git rebase --onto` doesn't\nadd source/origin information to commit description. The `(cherry\npicked from *)` line is extremely helpful in generating proper commit\nstatistics on a given branch, which is interesting because of a high\namount of commits coming from various non-vanilla remotes.\n\nReviewing the cherry picked commits, we extensively rely on patch id\ncomparison. We've developed scripts that extract the remote commit hash\nfrom the `(cherry picked from )` line in the commit\ndescription, in order to produce tables like below:\n\nRemote-commit-id Local-commit-id Patch-id-mismatch?\n No\n Yes\n---------------------------------\n No\n\nThis information helps the reviewer identify the non-clean picks, which\nare oftentimes (but not always) caused by manual conflict resolution,\nwhich we try to briefly document in square brackets above the\n`Signed-off-by` signature. We feel that documenting any manual conflict\nresolution is important, as it can be source of bugs if not done\nproperly.\n\nTroubles begin when we import out-of-tree kernel modules in-tree (some\nsuppliers delivery many of them). We use subtree cherry picking [1] for\nthat. Because subtree strategy alters the file-names, there will always\nbe a patch id mismatch between the origin commit and its pick. To\novercome this, we are using alternatives to `git patch-id`, which ignore\nfile-names. Here comes my actual question. Would it be conceptually fine\nto implement some `git patch-id` parameter, which would allow ignoring\nthe file-names (or reducing those to their `basename`) before computing\nthe patch id? Or would it break the concept of patch id (which shouldn't\naccept variations)?\n\nThank you.\nEugeniu.\n\n[1] git cherry-pick -x -s --no-merges --strategy=subtree -Xsubtree=drivers/staging/mymodule ..\n"},{"id":"333423","messageId":"xmqqlgiwm7x1.fsf@gitster.mtv.corp.google.com","threadId":"47310","inReplyTo":"20171124073327.GA15188@vmlxhi-102.adit-jv.com","subject":"Re: Make patch-id more flexible?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-24T07:51:06Z","receivedAt":"2017-11-24T07:51:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eugeniu Rosca writes:\n\n> file-names. Here comes my actual question. Would it be conceptually fine\n> to implement some `git patch-id` parameter, which would allow ignoring\n> the file-names (or reducing those to their `basename`) before computing\n> the patch id? Or would it break the concept of patch id (which shouldn't\n> accept variations)?\n\nMy gut feeling is that a tool like that would be fine as long as it\nis local to your organization and is not called \"git patch-id\"; it\nmay be useful in the situation you described, but as you mention\nabove, it feels that it is differnt from what a patch-id is.\n\n"},{"id":"333848","messageId":"20171130103539.GA19237@vmlxhi-102.adit-jv.com","threadId":"47310","inReplyTo":"xmqqlgiwm7x1.fsf@gitster.mtv.corp.google.com","subject":"Re: Make patch-id more flexible?","fromName":"Eugeniu Rosca","fromEmail":"erosca@de.adit-jv.com","sentAt":"2017-11-30T10:35:39Z","receivedAt":"2017-11-30T10:36:01Z","isPatch":false,"sender":{"key":"erosca@de.adit-jv.com","avatar":null},"body":"Hello Junio,\n\n> > file-names. Here comes my actual question. Would it be conceptually fine\n> > to implement some `git patch-id` parameter, which would allow ignoring\n> > the file-names (or reducing those to their `basename`) before computing\n> > the patch id? Or would it break the concept of patch id (which shouldn't\n> > accept variations)?\n> \n> My gut feeling is that a tool like that would be fine as long as it\n> is local to your organization and is not called \"git patch-id\"; it\n> may be useful in the situation you described, but as you mention\n> above, it feels that it is differnt from what a patch-id is.\n> \n\nThank you very much for your feedback. That's exactly I was looking for.\nA clear statement from the maintainer. We will live then with a custom\ntool that acts like `git patch-id`, just strips the patches from\nfile-names before computing the hash.\n\nBest regards,\nEugeniu.\n"}]}