All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Antoine Pelisse <apelisse@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH 0/5] "diff --stat" counting fixes
Date: Sat, 01 Dec 2012 18:23:22 -0800	[thread overview]
Message-ID: <7vhao5mbtx.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CALWbr2xYrWkfSCUc7gocVGLQP_RHjWrMmFspPe5O_ekjisNqxw@mail.gmail.com> (Antoine Pelisse's message of "Sat, 1 Dec 2012 11:29:53 +0100")

Antoine Pelisse <apelisse@gmail.com> writes:

> 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

Yes, it is redundant.  They are primarily meant as a warning to
anybody who runs "git diff --stat" while their index is not fully
merged so that they do not mistakenly think they are looking at
meaningful numbers.  The number of added lines likely includes the
conflict markers you haven't dealt with ;-)

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

Yeah, don't use shortstat while your index is unmerged.

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

Then your script wouldn't receive any hint in the output that you
are reading from a nonsense input.  When you see the same filename
twice, you will know there is something strange (not just "I seem to
have more added lines than I thought I added -- Ah, I see added
files from both sides because I still have conflicts unresolved")
that gives you a chance to notice.

      reply	other threads:[~2012-12-02  2:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27 21:21 [PATCH 0/5] "diff --stat" counting fixes Junio C Hamano
2012-11-27 21:21 ` [PATCH 1/5] test: add failing tests for "diff --stat" to t4049 Junio C Hamano
2012-11-27 21:21 ` [PATCH 2/5] diff --stat: status of unmodified pair in diff-q is not zero Junio C Hamano
2012-11-27 21:21 ` [PATCH 3/5] diff --stat: use "file" temporary variable to refer to data->files[i] Junio C Hamano
2012-11-27 21:21 ` [PATCH 4/5] diff --stat: move the "total count" logic to the last loop Junio C Hamano
2012-11-27 21:21 ` [PATCH 5/5] diff --stat: do not count "unmerged" entries Junio C Hamano
2012-11-27 22:21 ` [PATCH 6/5] diff --shortstat: " Junio C Hamano
2012-11-29  8:22 ` [PATCH] t4049: avoid test failures on filemode challenged file systems (Windows) Johannes Sixt
2012-11-29 16:13   ` Junio C Hamano
2012-11-29 17:51     ` Junio C Hamano
2012-11-29 20:48       ` Junio C Hamano
2012-11-30  7:46         ` Johannes Sixt
2012-12-02  2:24           ` Junio C Hamano
2012-12-01 10:29 ` [PATCH 0/5] "diff --stat" counting fixes Antoine Pelisse
2012-12-02  2:23   ` Junio C Hamano [this message]

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=7vhao5mbtx.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=apelisse@gmail.com \
    --cc=git@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.