On 05/16/2012 08:12 PM, Junio C Hamano wrote: > 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. Yes it would make sense for `git am` to balk at such reduced patches, while allowing standard patch utilities to process the patches as normal. 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