* Re: [PATCH] Libify diff-files.
[not found] <7vbqutlxwq.fsf@assigned-by-dhcp.cox.net>
@ 2006-04-22 10:52 ` Junio C Hamano
0 siblings, 0 replies; only message in thread
From: Junio C Hamano @ 2006-04-22 10:52 UTC (permalink / raw)
To: git; +Cc: torvalds, pasky
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.
^ permalink raw reply [flat|nested] only message in thread