From: Junio C Hamano Date: Wed, 16 May 2012 19:12:27 GMT Subject: Re: git format-patch doesn't exclude merged hunks Message-ID: <7v8vgsc544.fsf@alter.siamese.dyndns.org> In-Reply-To: <4FB3FA59.1010707@draigBrady.com> Pádraig Brady 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.