Re: [PATCH] apply.c: tolerate diff from a dirty but unchanged path

[Junio C Hamano <junkio@cox.net>]

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

LT> One-liner fix checked in: we should ignore all git headers that are just a 
LT> single line. A valid git header is _always_ multiple lines: either you 
LT> have the "---/+++" lines of a diff, or you have the old/new lines of a 
LT> mode or name change.

Yup.  I was about to say "it always amazes me" but by now I
should instead say "I am used to see" that your fix to my
crapola is always cleaner, simpler, and shorter.

By the way, just to help you sort the heap of recent patches
from me, here is the list of patches from me not in your tree
that I think you _could_ consider.  Other patches I posted to
the list that have not been merged are mostly earlier attempts
that I consider you have already discarded; there _could_ be
something I am forgetting, but if even I myself forget, they
probably do not matter ;-):

------------
This is a fix for a bug that would embarrass me unless fixed.

    Subject: [PATCH] Fix rename/copy when dealing with temporarily broken...
    Date: Sat, 11 Jun 2005 20:55:20 -0700
    Message-ID: <7vwtp0p6tz.fsf@assigned-by-dhcp.cox.net>

A good test case is to run and compare these two in the GIT
repository.  The latter case is mishandled with unpatched code:

    commit=7ef76925d9c19ef74874e1735e2436e56d0c4897
    git-diff-tree -C $commit
    git-diff-tree -B -C $commit

------------
This one adjusts what the tutorial tells the user to expect to
the reality with the "corrected" -B behaviour we already have in
your tree.  We must have this before 1.0 in order not to confuse
the reader.  Unless you drop -B from git-status-script, that is.

    Subject: [PATCH 5/4] Tutorial update to adjust for -B fix
    Date: Fri, 03 Jun 2005 12:11:07 -0700
    Message-ID: <7vd5r3l0hg.fsf_-_@assigned-by-dhcp.cox.net>

------------
These two are enhancements that would help writing the
ultra-smart three-way merge that would look at not just merge
base and two heads, but the changes in the ancestry chain:

    Message-ID: <7vpsut7k89.fsf@assigned-by-dhcp.cox.net>
    Subject: [PATCH] diff-tree: --find-copies-harder
    Date: Fri, 10 Jun 2005 18:31:02 -0700

    Message-ID: <7vr7f8p6qu.fsf@assigned-by-dhcp.cox.net>
    Subject: [PATCH] Add --diff-filter= output restriction to diff-* family.
    Date: Sat, 11 Jun 2005 20:57:13 -0700

I mentioned them in the reply to this message from you:

    Date: Thu, 9 Jun 2005 08:15:52 -0700 (PDT)
    Subject: Re: [PATCH 3/3] read-tree -m 3-way: handle more trivial merges
    Message-ID: <Pine.LNX.4.58.0506090800580.2286@ppc970.osdl.org>

    No, I think this is quite possibly wrong for several reasons.
    ...
    So I just need a little convincing that this is a good idea.

------------
These are reworked "help carrying forward local changes in 2-way
fast forward".

    Message-ID: <7vd5qt7k2d.fsf@assigned-by-dhcp.cox.net>
    Subject: [PATCH 1/3] Clean up read-tree two-way tests.
    Date: Fri, 10 Jun 2005 18:34:34 -0700

    Message-ID: <7v7jh17jzr.fsf@assigned-by-dhcp.cox.net>
    Subject: [PATCH 2/3] read-tree --emu23.
    Date: Fri, 10 Jun 2005 18:36:08 -0700

    Message-ID: <7v1x797jx0.fsf@assigned-by-dhcp.cox.net>
    Subject: [PATCH 3/3] read-tree: fix too strong index requirement #5ALT
    Date: Fri, 10 Jun 2005 18:37:47 -0700

    Message-ID: <7voeadxlvo.fsf@assigned-by-dhcp.cox.net>
    Subject: [PATCH 4/3] Finish making --emu23 equivalent to pure 2-way merge.
    Date: Sat, 11 Jun 2005 02:50:51 -0700

    Message-ID: <7vfyvpxlqi.fsf@assigned-by-dhcp.cox.net>
    Subject: [PATCH 5/3] read-tree: loosen too strict index requirements
    Date: Sat, 11 Jun 2005 02:53:57 -0700

The first four implement --emu23, a two-tree fast forward
emulated internally using the three-way mechanism.  This is to
help cases where the user has local changes since the old head
by not refusing to run in many cases straight 2-tree fast
forward would refuse, and letting the user use the usual
merge-cache three-way merge postprocessing machinery to carry
local changes forward instead.

The changes these four introduce do affect 3-way in 3 cases,
which you objected, but this set has smaller impact than my
earlier attempts.  It only resolves 3 extra cases the original
3-way refuses to touch (my earlier one made it to resolve 3
cases that involve removed paths as well, none of which this
round touches, and leaves stages in the resulting index).  The
cases new code internally resolves, instead of refusing to run,
are:

 - only "merged head" created a new path, and the index happened
   to have the same change; we resolve it internally by taking
   the "merged head" and keep the index dirty if it was (#2ALT).

 - only "our head" created a new path, and the cache entry is
   dirty (i.e. user has local changes in the work tree file); we
   resolve it internally by taking "our head" and keep the index
   dirty if it was (#3ALT).

 - both "merged head" and "our head" created a new path
   identically, and the cache entry is dirty; we resolve it
   internally by taking "our head" and keep the index dirty if
   it was (#5ALT).

I think your earlier objection of "closing the door to the
clever merge algorithm" would not apply to these three cases.
Note that --emu23 does not need 3-way code to resolve the #2ALT
case, but needs the other two cases not refused; the patch makes
it resolve #2ALT case only to keep things symmetric with #3ALT
case --- otherwise users of 3-way merge would get confusing (but
still correct) results.

The last one [5/3] deals with the case where a path is only
changed in the merged head in 3-way case, and the index already
happens to have a version from the merged head (probably the
user was playing with a patch floating around in the mailing
list before initiating the merge).  In this case we can make the
3-way merge succeed instead of refusing to run, and that is what
this patch is about.  This does not change the outcome of the
merge, and I think your "closing the door" objection would not
apply to it.

------------
This is to enhance the git-*-script suite.  I do not mind too
much if it stays outside, but I think it would be useful to
other people as well, not just me.

    Message-ID: <7vll5h7k5t.fsf@assigned-by-dhcp.cox.net>
    Subject: [PATCH] Add script for patch submission via e-mail.
    Date: Fri, 10 Jun 2005 18:32:30 -0700

------------
This attempts to split the "too big main() that does it all"
which you hated.  Purely cosmetic at this point but as you
pointed out it is a good discipline to help later maintenance to
have a set of smaller single-task functions.

    Message-ID: <7vu0k56517.fsf_-_@assigned-by-dhcp.cox.net>
    Subject: [PATCH] diff-stages: unuglify the too big main() function.
    Date: Fri, 10 Jun 2005 18:44:36 -0700