"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > git format-patch is often used to create patches that are then stored in > version control or displayed with diff. Having the commit hash in the > "From " line usually just creates diff noise in these cases, so this > series introduces --no-hash to set that to all zeros. I am somewhat negative on this change that deliberately loses information in a way that seems too specific to a single workflow. I understand that in that particular workflow, the patch stored as payload in a history needs only the diff part and the commit that the patch was taken from is deemed irrelevant. But the reason why that and only that piece of information is expendable, while author, subject and log message text are not is because...? The answer to that question would very much be project's workflow dependant. From that point of view, I'd say the users are much better off without the addition of this feature, but have a custom script in their workflow to remove parts that their project and workflow deems unnecessary. Your project may deem the source commit object name unnecessary. Another one may think the author date and name are, too. Patch e-mail signature (i.e. what comes after a line with "-- ") by default depends on the version of Git that happened to have been used to prepare the patch, which may not be something you would want. Stepping back a bit, why is the history from which the patches are taken from irrelevant in the first place? Perhaps because you replayed these patches on top of the same base but did not preserve their timestamps? If this user, i.e. the part of the workflow that commits generated patches to version control, finds the "irrelevant" change irritating, isn't it fair to expect other users, i.e. other parts of the same workflow, also find that unnecessary and irrelevant rebasing irritating? It feels like I am seeing an entrance to an X-Y problem whose real solution is to stop doing the pointless rebases in the first place. And if that rebase is not pointless, then I am not sure if it is a good thing to discard the information that records which incarnation of that constantly rebased source tree the patches were taken from. So... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html