On 05/16/2012 07:49 PM, Junio C Hamano wrote: > Pádraig Brady <P@xxxxxxxxxxxxxx> writes: > >> For reference the two commits in question are: >> https://github.com/openstack/nova/commit/7028d66 >> https://github.com/openstack/nova/commit/26dc6b7 >> Notice how both make the same change to Authors. > > If you compare the changes these two commits introduce, you will also > notice that the "Authors" file is the _only_ common part of them. > > "format-patch" (more precicely, the "git cherry" machinery that identifies > the same patch) does not _selectively_ drop only a part of a patch while > keeping the other parts. It is not per "hunk", it is not even per "file". > > This is very much on purpose, and I think it is a good design decision. > > In this particular case, the behaviour does look suboptimal, but if you > think about it harder, you will realize that the perception comes largely > because in this particular commit, the change to the "Authors" file is the > least interesting part of the change. > > Imagine a case where you were replaying a commit that changes a file > significantly and also changes another file in a trivial way, and where it > were the significant change that has already been applied to the receiving > codebase, not the insignificant change to "Authors" file. > > Now imagine that format-patch dropped the part that brings in the > significant change as duplicate, and replayed only the insignificant part. > Most likely, the log message of the original commit explains what issue > that significant change tried to solve, and how the implementation in the > patch was determined to be an acceptable approach to solve it, and that is > what you will be recording for the replayed commit that only introduces > the remaining insignificant change. > > I am not fundamentally opposed to the idea of (optionally) detecting and > selectively dropping parts of a patch to an entire file or even hunks that > have already applied, but it needs to have a way remind the user somewhere > in the workflow that it did so and the log message may no longer describe > what the change does. Most likely it would have to be done when producing > format-patch output, but an approach to make it a responsibility to notice > and fix the resulting log message to the person who applies the output, I > would imagine. Yep agreed, it would have to be optional. Maybe --ignore-duplicate-changes ? Appending a marker to the commit message of the adjusted patch would make sense, similar to how a 'Conflicts:' list is auto generated for commit messages. cheers, Pádraig. -- 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