delta/git.git/diffcore-rename.c, branch jn/gitweb-side-by-side-diff github.com: git/git.git Merge branch 'mz/maint-rename-unmerged' 2011-05-02T22:58:27+00:00 Junio C Hamano gitster@pobox.com 2011-05-02T22:58:27+00:00 2db8926236406a4e4cb17d1b9c4b791706fb0512 * mz/maint-rename-unmerged: diffcore-rename: don't consider unmerged path as source 
* mz/maint-rename-unmerged:
  diffcore-rename: don't consider unmerged path as source
diffcore-rename.c: avoid set-but-not-used warning 2011-04-29T15:20:10+00:00 Jim Meyering jim@meyering.net 2011-04-29T09:42:41+00:00 dabdbee10bd6c7d92204ce4bfc1f3ffd60a4046a Since 9d8a5a5 (diffcore-rename: refactor "too many candidates" logic, 2011-01-06), diffcore_rename() initializes num_src but does not use it anymore. "-Wunused-but-set-variable" in gcc-4.6 complains about this. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 
Since 9d8a5a5 (diffcore-rename: refactor "too many candidates" logic,
2011-01-06), diffcore_rename() initializes num_src but does not use it
anymore.  "-Wunused-but-set-variable" in gcc-4.6 complains about this.

Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore-rename: don't consider unmerged path as source 2011-03-24T05:44:22+00:00 Martin von Zweigbergk martin.von.zweigbergk@gmail.com 2011-03-24T02:41:01+00:00 d7c9bf22351e39756f93f09b4251a6b5861d9cc0 Since e9c8409 (diff-index --cached --raw: show tree entry on the LHS for unmerged entries., 2007-01-05), an unmerged entry should be detected by using DIFF_PAIR_UNMERGED(p), not by noticing both one and two sides of the filepair records mode=0 entries. However, it forgot to update some parts of the rename detection logic. This only makes difference in the "diff --cached" codepath where an unmerged filepair carries information on the entries that came from the tree. It probably hasn't been noticed for a long time because nobody would run "diff -M" during a conflict resolution, but "git status" uses rename detection when it internally runs "diff-index" and "diff-files" and gives nonsense results. In an unmerged pair, "one" side can have a valid filespec to record the tree entry (e.g. what's in HEAD) when running "diff --cached". This can be used as a rename source to other paths in the index that are not unmerged. The path that is unmerged by definition does not have the final content yet (i.e. "two" side cannot have a valid filespec), so it can never be a rename destination. Use the DIFF_PAIR_UNMERGED() to detect unmerged filepair correctly, and allow the valid "one" side of an unmerged filepair to be considered a potential rename source, but never to be considered a rename destination. Commit message and first two test cases by Junio, the rest by Martin. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 
Since e9c8409 (diff-index --cached --raw: show tree entry on the LHS for
unmerged entries., 2007-01-05), an unmerged entry should be detected by
using DIFF_PAIR_UNMERGED(p), not by noticing both one and two sides of
the filepair records mode=0 entries. However, it forgot to update some
parts of the rename detection logic.

This only makes difference in the "diff --cached" codepath where an
unmerged filepair carries information on the entries that came from the
tree.  It probably hasn't been noticed for a long time because nobody
would run "diff -M" during a conflict resolution, but "git status" uses
rename detection when it internally runs "diff-index" and "diff-files"
and gives nonsense results.

In an unmerged pair, "one" side can have a valid filespec to record the
tree entry (e.g. what's in HEAD) when running "diff --cached". This can
be used as a rename source to other paths in the index that are not
unmerged. The path that is unmerged by definition does not have the
final content yet (i.e. "two" side cannot have a valid filespec), so it
can never be a rename destination.

Use the DIFF_PAIR_UNMERGED() to detect unmerged filepair correctly, and
allow the valid "one" side of an unmerged filepair to be considered a
potential rename source, but never to be considered a rename destination.

Commit message and first two test cases by Junio, the rest by Martin.

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore-rename: fall back to -C when -C -C busts the rename limit 2011-03-22T21:29:07+00:00 Junio C Hamano gitster@pobox.com 2011-01-06T21:50:06+00:00 f31027c99cb2ec4eb7ad8d1ebc7f0e20fef4bd1d When there are too many paths in the project, the number of rename source candidates "git diff -C -C" finds will exceed the rename detection limit, and no inexact rename detection is performed. We however could fall back to "git diff -C" if the number of modified paths is sufficiently small. Signed-off-by: Junio C Hamano <gitster@pobox.com> 
When there are too many paths in the project, the number of rename source
candidates "git diff -C -C" finds will exceed the rename detection limit,
and no inexact rename detection is performed.  We however could fall back
to "git diff -C" if the number of modified paths is sufficiently small.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore-rename: record filepair for rename src 2011-03-22T21:29:07+00:00 Junio C Hamano gitster@pobox.com 2011-01-06T21:50:05+00:00 e88d6bc6f90059f6e87f6d51eba83ec15e4eecc9 This will allow us to later skip unmodified entries added due to "-C -C". We might also want to do something similar to rename_dst side, but that would only be for the sake of symmetry and not necessary for this series. Signed-off-by: Junio C Hamano <gitster@pobox.com> 
This will allow us to later skip unmodified entries added due to "-C -C".
We might also want to do something similar to rename_dst side, but that
would only be for the sake of symmetry and not necessary for this series.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore-rename: refactor "too many candidates" logic 2011-03-22T21:29:07+00:00 Junio C Hamano gitster@pobox.com 2011-01-06T21:50:04+00:00 9d8a5a50b7e30d85aff3deac2a6994bf0178983d Move the logic to a separate function, to be enhanced by later patches in the series. While at it, swap the condition used in the if statement from "if it is too big then do this" to "if it would fit then do this". Signed-off-by: Junio C Hamano <gitster@pobox.com> --- Rebased to 'master' as the logic to use the result of this logic was updated recently, together with the addition of eye-candy. 
Move the logic to a separate function, to be enhanced by later patches in
the series.

While at it, swap the condition used in the if statement from "if it is
too big then do this" to "if it would fit then do this".

Signed-off-by: Junio C Hamano <gitster@pobox.com>

---

 Rebased to 'master' as the logic to use the result of this logic was
 updated recently, together with the addition of eye-candy.
Merge branch 'jk/merge-rename-ux' 2011-03-20T06:23:56+00:00 Junio C Hamano gitster@pobox.com 2011-03-20T06:23:56+00:00 0ce6a51b43815a34d0dbebaa799b32a83d1ea4f9 * jk/merge-rename-ux: pull: propagate --progress to merge merge: enable progress reporting for rename detection add inexact rename detection progress infrastructure commit: stop setting rename limit bump rename limit defaults (again) merge: improve inexact rename limit warning 
* jk/merge-rename-ux:
  pull: propagate --progress to merge
  merge: enable progress reporting for rename detection
  add inexact rename detection progress infrastructure
  commit: stop setting rename limit
  bump rename limit defaults (again)
  merge: improve inexact rename limit warning
add inexact rename detection progress infrastructure 2011-02-21T18:24:07+00:00 Jeff King peff@peff.net 2011-02-20T09:51:16+00:00 3ac942d42ebb1fb48e70d3e5a714d06396e3e2c6 We might spend many seconds doing inexact rename detection with no output. It's nice to let the user know that something is actually happening. This patch adds the infrastructure, but no callers actually turn on progress reporting. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 
We might spend many seconds doing inexact rename detection
with no output.  It's nice to let the user know that
something is actually happening.

This patch adds the infrastructure, but no callers actually
turn on progress reporting.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge: improve inexact rename limit warning 2011-02-21T18:21:26+00:00 Jeff King peff@peff.net 2011-02-19T10:20:51+00:00 bf0ab10fa84df6c49450a06077d1c52756d88222 The warning is generated deep in the diffcore code, which means that it will come first, followed possibly by a spew of conflicts, making it hard to see. Instead, let's have diffcore pass back the information about how big the rename limit would needed to have been, and then the caller can provide a more appropriate message (and at a more appropriate time). No refactoring of other non-merge callers is necessary, because nobody else was even using the warn_on_rename_limit feature. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 
The warning is generated deep in the diffcore code, which
means that it will come first, followed possibly by a spew
of conflicts, making it hard to see.

Instead, let's have diffcore pass back the information about
how big the rename limit would needed to have been, and then
the caller can provide a more appropriate message (and at a
more appropriate time).

No refactoring of other non-merge callers is necessary,
because nobody else was even using the warn_on_rename_limit
feature.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore-rename: improve estimate_similarity() heuristics 2011-02-19T06:26:45+00:00 Linus Torvalds torvalds@linux-foundation.org 2011-02-19T04:12:06+00:00 3a4d67692b5a80213ca47a603fa5505a5990cc87 The logic to quickly dismiss potential rename pairs was broken. It would too eagerly dismiss possible renames when all of the difference was due to pure new data (or deleted data). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 
The logic to quickly dismiss potential rename pairs was broken.  It
would too eagerly dismiss possible renames when all of the difference
was due to pure new data (or deleted data).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>