git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] The diff-raw format updates.
Date: Sun, 22 May 2005 17:35:51 -0700	[thread overview]
Message-ID: <7vu0kubwyg.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0505221611020.2307@ppc970.osdl.org> (Linus Torvalds's message of "Sun, 22 May 2005 16:14:23 -0700 (PDT)")

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

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

I do agree that it is a real problem.

And I think you've filled some holes in the idea I originally
had while working on the following (the part you omitted from
the quote):

    ...  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).

The change I am making right now is essentially what the above
paragraph says, with your "hole-filling", to do something like
this:

 (1) diff-tree family feeds unmodified entries to the diffcore,
     in addition to changes.  diffcore-rename matches and merges
     them into rename/copy; diffcore-pickaxe filters; other
     diffcore transformations may later be written (e.g
     reordering the patch so that .h files come first before .c
     files).  The result of the sequence of these
     transformations is fed to the diff_flush() for output.
     Essentially this is the same architecture as we already
     have.

 (2) diff_flush() currently prunes _all_ the unmodified entries
     just before output happens.  This is a _bug_ as you said.
     To fix this, first, separate that pruning part (which is
     currently embedded in diff_flush_one as the first
     statement) out, so this pruning happens independently and
     before diff_flush() happens; and make the pruning more
     careful, not to prune entries that we _need_ to express
     rename/copy distinction in diff-raw output.  Namely, it
     should keep the unmodified entry for a path _if_ the path
     is to be used as the source of a rename or copy entry.
     Also diff-patch output needs to be taught to take notice
     and ignore such entries.

     Optionally, the callers may want to tell diffcore not to do
     _any_ pruning, making diff-raw output similar to a merge of
     ls-files --stage outputs of two trees.

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

To this, I 100% agree, and I think it is doable.  Give me a bit
more time for testing and tweaking.


  reply	other threads:[~2005-05-23  0:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-21 23:12 updated design for the diff-raw format Junio C Hamano
2005-05-21 23:16 ` Junio C Hamano
2005-05-21 23:17 ` Junio C Hamano
2005-05-21 23:18 ` Junio C Hamano
2005-05-21 23:19 ` Junio C Hamano
2005-05-22  2:40 ` [PATCH] Prepare diffcore interface for diff-tree header supression Junio C Hamano
2005-05-22  2:42   ` [PATCH] The diff-raw format updates Junio C Hamano
2005-05-22  6:01     ` Linus Torvalds
2005-05-22  6:33       ` Junio C Hamano
2005-05-22  6:57       ` Junio C Hamano
2005-05-22  8:31         ` [PATCH] Fix tweak in similarity estimator Junio C Hamano
2005-05-22 18:35     ` [PATCH] The diff-raw format updates Linus Torvalds
2005-05-22 18:36       ` Niklas Hoglund
2005-05-22 19:15         ` Junio C Hamano
2005-05-22 18:42       ` Thomas Glanzmann
2005-05-22 19:05         ` Linus Torvalds
2005-05-22 19:05           ` Thomas Glanzmann
2005-05-22 19:20           ` Junio C Hamano
2005-05-22 19:35             ` Junio C Hamano
2005-05-22 20:24               ` Linus Torvalds
2005-05-22 23:01                 ` Junio C Hamano
2005-05-22 23:14                   ` Linus Torvalds
2005-05-23  0:35                     ` Junio C Hamano [this message]
2005-05-23  1:07                       ` Linus Torvalds
2005-05-23  1:33                         ` Junio C Hamano
2005-05-23  4:26               ` [PATCH] Rename/copy detection fix Junio C Hamano
2005-05-23  4:38                 ` Comments on "Rename/copy detection fix." Junio C Hamano
2005-05-22 19:13       ` [PATCH] The diff-raw format updates Junio C Hamano
2005-05-22  9:41   ` [PATCH] Diffcore updates Junio C Hamano
2005-05-22 16:40     ` Linus Torvalds
2005-05-22 16:47       ` Junio C Hamano
2005-05-22 17:04     ` Junio C Hamano
2005-05-23  4:24       ` [PATCH] Be careful with symlinks when detecting renames and copies Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vu0kubwyg.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=sithglan@stud.uni-erlangen.de \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).