Junio C Hamano wrote:
Michał Kiedrowicz <michal.kiedrowicz@xxxxxxxxx> writes:
... However, there are some cases when these two
rules may cause problems:
patch #1: rename A to B
patch #2: rename C to A
patch #3: modify A
Should patch #3 modify B (which was A) or A (which was C)?
patch #1: rename A to B
patch #2: rename B to A
patch #3: modify A
patch #4: modify B
Which files should be patched by #3 and #4?
In my opinion both #3 and #4 should fail (or both should succeed) --
with my patch only #3 will work and #4 will be rejected, because in #2
B was marked as deleted.
Both of the examples above cannot be emitted as a single commit by
format-patch; the user is feeding a combined patch. Perhaps renames
in each example sequence were came from one git commit but modifications
are from separate commit or handcrafted "follow-up" patch.
There are two stances we can take:
(1) The user knows what he is doing.
In the first example, if he wanted the change in #3 to end up in B,
he would have arranged the patches in a different order, namely, 3 1
2, but he didn't. We should modify A (that came from C).
This gets my vote. Standard "diff -u" patches have always had to be
numbered properly if they have even the slightest chance of interfering
with each other, so developers are already used to it.
/Andreas
--
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