From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Cc: torvalds@osdl.org, pasky@suse.cz
Subject: Re: [PATCH] Libify diff-files.
Date: Sat, 22 Apr 2006 03:52:00 -0700 [thread overview]
Message-ID: <7vfyk5khm7.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <7vbqutlxwq.fsf@assigned-by-dhcp.cox.net> (Junio C. Hamano's message of "Sat, 22 Apr 2006 03:14:45 -0700")
I noticed that there are two flags related to missing working
tree files in diff-files and diff-index. The former takes -q
to mean "do not report lossage of working tree files", and the
latter uses -m to mean "when not using --cached, pretend that
missing working tree files are actually present and match the
index".
Being able to pretend missing working tree files are unchanged
was originally done to help merging in a separate temporary
area, and it is useful, but I wish we used the same flag. I
started wondering if we can unify them to '-q', since '-m'
means "do not ignore merges" in diff-tree context (including
log and whatchanged).
NOTE. -q is different from specifying --diff-filter=ACMRTU;
while the former does not even feed the filepair to diffcore,
the latter tells the diffcore to filter deletion out in the
output phase. The distinction makes huge difference when the
rename/copy detection, especially without --find-copies-harder,
is involved.
Now, as far as I can tell, nobody uses "diff-files -q". Cogito
uses "diff-index -m" quite a bit, but I suspect large part of it
is remnant from the days it did a merge in a separate directory,
and/or a cut-and-paste error from neighbouring "diff-tree -m -r".
A cursory look suggests some could even be bugs. For example,
cg-patch has
diff-tree -m -r "$commitparent" "$commitid"
(where -m does not have any effect) which is immediately
followed by a
diff-index -m -r HEAD
where -m may or may not be intended.
parent reply other threads:[~2006-04-22 20:44 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <7vbqutlxwq.fsf@assigned-by-dhcp.cox.net>]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vfyk5khm7.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=pasky@suse.cz \
--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.
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 NNTP newsgroup(s).