That does make a lot of sense and I would have indeed missed a couple
of things here.
I've been thinking about that "Unmerged" line quite a lot, and I can't
get myself any good reason to keep it.
Would you mind taking a couple of minutes to make it clear ?
I feel like (but I can obviously be wrong):
1. The info is redundant. When performing a merge, all diffs (without
--staged flag) are unmerged
2. While status shows the line once, while diff shows the diff for the file
once, while diff --shortstat counts the file once, diff --stat shows two
lines for the file.
3. diff --numstat shows two lines for the same file. As a script
writer (I guess that's what it's meant for), I would definitely expect
uniqueness in third column/filenames.
On Tue, Nov 27, 2012 at 10:21 PM, Junio C Hamano <gits...@pobox.com> wrote:
> It turns out that there are at least two bugs in the diffstat
> counting code. This series comes on top of the earlier 74faaa1 (Fix
> "git diff --stat" for interesting - but empty - file changes,
> 2012-10-17) to fix them.
> Junio C Hamano (5):
> test: add failing tests for "diff --stat" to t4049
> diff --stat: status of unmodified pair in diff-q is not zero
> diff --stat: use "file" temporary variable to refer to data->files[i]
> diff --stat: move the "total count" logic to the last loop
> diff --stat: do not count "unmerged" entries
> diff.c | 49
> t/t4049-diff-stat-count.sh | 46 ++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 72 insertions(+), 23 deletions(-)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html