On Fri, Oct 14, 2022 at 10:13 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Jerry Zhang via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: Jerry Zhang <Jerry@xxxxxxxxxx> > > > > "git patch-id" currently doesn't produce correct output if the > > incoming diff has any binary files. Add logic to > > get_one_patchid to handle the different possible styles of binary > > diff. This attempts to keep resulting patch-ids identical to what > > would be produced by the counterpart logic in diff.c, that is it > > produces the id by hashing the a and b oids in succession. > > It is sad that we have two separate implementations in the first > place. Do you see if it is feasible to unify the implementation > by reusing one from the other (answering this is not a requirement > for this patch to be looked at)? Yeah I wondered this myself, it's tricky because they are actually doing opposite things: the diff.c logic is adding diff metadata before doing the patch-id, while the patch-id logic is parsing out the diff metadata. We could refactor it, but would have to be careful not to accidentally change the output semantics. Another possible path to "unifying" the logic would be to add a "--patch-id" mode to "git diff' that produces the patch-id of what would be the diff, rather than the diff itself. For the usecases that involve piping "git diff" into "git patch-id", this would require not needing the separate patch-id tool at all. Of course people also like to run "patch-id" on the output of "format-patch" after the fact so this isn't a perfect solution either. Speaking of which, do you have some context as to why we promise that "git patch-id" output will remain the same across git versions? Were there cases in the past where people actually made persistent databases of patch-ids, or complained about the output changing? I ask because this requirement makes it difficult to make big changes, and there aren't any tests to verify consistent output between git versions. Also git itself is already a persistent database of patches, so I'm not sure why someone would choose to implement a new system for this. >
