From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=
Subject: Re: git format-patch doesn't exclude merged hunks
Date: Wed, 16 May 2012 21:13:50 +0100
Message-ID: <4FB40A7E.80705@draigBrady.com>
References: <4FB3CAE3.6040608@draigBrady.com> <7vhavgc660.fsf@alter.siamese.dyndns.org> <4FB3FA59.1010707@draigBrady.com> <7v8vgsc544.fsf@alter.siamese.dyndns.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: git@vger.kernel.org
To: Junio C Hamano writes:
>=20
>> On 05/16/2012 07:49 PM, Junio C Hamano wrote:
>>
>>> I am not fundamentally opposed to the idea of (optionally) detectin=
g and
>>> selectively dropping parts of a patch to an entire file or even hun=
ks that
>>> have already applied, but it needs to have a way remind the user so=
mewhere
>>> in the workflow that it did so and the log message may no longer de=
scribe
>>> what the change does. Most likely it would have to be done when pr=
oducing
>>> 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 out=
put, 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 mess=
ages.
>=20
> These existing "conflicts:" are offered when recording manual resolut=
ions
> of a conflicting merge, and the user is actively thrown into an edito=
r
> when running "git commit" to record the result.
>=20
> A patch that is reduced in a way you propose will apply to the receiv=
ing
> tree cleanly without stopping, and does not offer an editor session t=
o
> adjust the log before making a commit. "The user has a chance to not=
ice
> and correct" is not sufficient---nobody will spend extra effort to no=
tice
> 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=C3=A1draig.