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 20:04:57 +0100
Message-ID: <4FB3FA59.1010707@draigBrady.com>
References: <4FB3CAE3.6040608@draigBrady.com> <7vhavgc660.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
>> 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.
>=20
> If you compare the changes these two commits introduce, you will also
> notice that the "Authors" file is the _only_ common part of them.
>=20
> "format-patch" (more precicely, the "git cherry" machinery that ident=
ifies
> the same patch) does not _selectively_ drop only a part of a patch wh=
ile
> keeping the other parts. It is not per "hunk", it is not even per "f=
ile".
>=20
> This is very much on purpose, and I think it is a good design decisio=
n.
>=20
> In this particular case, the behaviour does look suboptimal, but if y=
ou
> think about it harder, you will realize that the perception comes lar=
gely
> because in this particular commit, the change to the "Authors" file i=
s the
> least interesting part of the change.
>=20
> Imagine a case where you were replaying a commit that changes a file
> significantly and also changes another file in a trivial way, and whe=
re it
> were the significant change that has already been applied to the rece=
iving
> codebase, not the insignificant change to "Authors" file.
>=20
> 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 iss=
ue
> that significant change tried to solve, and how the implementation in=
the
> patch was determined to be an acceptable approach to solve it, and th=
at is
> what you will be recording for the replayed commit that only introduc=
es
> the remaining insignificant change.
>=20
> 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 some=
where
> in the workflow that it did so and the log message may no longer desc=
ribe
> what the change does. Most likely it would have to be done when prod=
ucing
> format-patch output, but an approach to make it a responsibility to n=
otice
> and fix the resulting log message to the person who applies the outpu=
t, 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 ma=
ke sense,
similar to how a 'Conflicts:' list is auto generated for commit message=
s.
cheers,
P=C3=A1draig.