Re: [PATCH] The diff-raw format updates.

quoted

quoted

quoted

quoted

"LT" == Linus Torvalds [off-list ref] writes:

LT> On Sun, 22 May 2005, Junio C Hamano wrote:

quoted

I deliberatly chose not to record rename/copy distinction in diff-raw

--- it is to be inferred from which entry touches the src _last_.  

Everything but the last one to touch the same path is copy, and the last
one is rename.

LT> My counter-example: there is no rename at all, just a copy.

My wording was wrong.  If you do not use the helper, you should
be able to get copy and in-place edit or no-modification (I
collectively call them "stay" in diffcore-rename.c).  If it does
not work then you have spotted a bug in the implementation but
not the design.  Anyway, I should have said:

    Everything but the last are copies.  If the last one have
    different src and dst, then it is a rename.  Otherwise it
    is a "stay".

LT> Try it. I added in the "&& detect_rename < 2" thing to diff-tree.c, and I 
LT> get:

LT> 	git-whatchanged -C --root | git-diff-helper | less -S

LT> resulting in:

That's not a counter-example.  You are agreeing to what I said in
this message:

    To: Linus Torvalds [off-list ref]
    Cc: git@vger.kernel.org
    Subject: [PATCH] Teach diff-tree to report unmodified paths for -C option.
    Date: Sat, 21 May 2005 03:11:49 -0700
    Message-ID: [off-list ref]

    ...

    Another useless comment.  For obvious reasons, there is nothing
    we can do about the diff-helper to add "the other half of copy
    detection information", because what it can tell diff-core is
    limited to its input, which usually is just differences prepared
    by somebody else, and it cannot know anything about unchanged
    files.  When I started pushing '-p' flag to diff-tree family, I
    remember that your reaction was neutral to moderately negative
    ("I'd tolerate, although I think it is redundant and you are not
    even generating diff yourself anyway" as opposed to "That's just
    great").  I think now you would thank me for shoving the diff
    interface into them ;-).

If you want the diff-helper to be able to the full scale copy
detection, you must _feed_ the full information including "stay"
entries to it.  Unfortunately, the current diffcore interface
does not let the callers (diff-tree family) to tell it to keep
the "stay" entries in its output.  I've been working on that
part this morning before this discussion started, so that
electively they can tell the diffcore layer not to do the "stay"
pruning ("stay pruning" will simply become another diffcore
transformation).

I have to leave again now, but I promise you'll hear back from
me on this one later tonight (or tomorrow evening at the latest
if things do not work out).

On Sun, 22 May 2005, Junio C Hamano wrote:

    Everything but the last are copies.  If the last one have
    different src and dst, then it is a rename.  Otherwise it
    is a "stay".

If so, I disagree. Totally.

You seem to think that it's a feature that you can't get the same output 
out of git-diff-helper, and I think that's not a feature, but a total bug.

LT> resulting in:

That's not a counter-example.  You are agreeing to what I said in
this message:

No, I'm not agreeing at all. I'm saying that this is unacceptable, and if 
this was intentional, as you seem to be saying, then it was in my opinion 
a bad idea. We might as well go back to the original diff format, which 
had other problems, but they were no worse than the new one.

Basically, with the new format as-is, renames and copies cannot be 
described sanely. That was exactly the same problem as the old format had, 
except the old format was less verbose. So why do the new format at all?

I'm arguing that we should consider it a _requirement_ that "raw diffs" 
can be translated into te same thing the "-p" flag internally does.

		Linus