Pádraig Brady <P@xxxxxxxxxxxxxx> writes: > On 05/16/2012 07:49 PM, Junio C Hamano wrote: > >> 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. These existing "conflicts:" are offered when recording manual resolutions of a conflicting merge, and the user is actively thrown into an editor when running "git commit" to record the result. A patch that is reduced in a way you propose will apply to the receiving tree cleanly without stopping, and does not offer an editor session to adjust the log before making a commit. "The user has a chance to notice and correct" is not sufficient---nobody will spend extra effort to notice let alone correct. The reminder has to be a lot stronger than that, I think, to cause the patch application to "fail" and require the user to actively look at the situation. -- 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