From: Junio C Hamano <gitster@pobox.com>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Jacob Keller <jacob.keller@gmail.com>,
Dennis Kaarsemaker <dennis@kaarsemaker.net>,
Git mailing list <git@vger.kernel.org>
Subject: Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)
Date: Mon, 14 Nov 2016 10:01:29 -0800 [thread overview]
Message-ID: <xmqqoa1ix7nq.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <0c39be16-76f8-0800-41a2-b7b1dccdd652@drmicha.warpmail.net> (Michael J. Gruber's message of "Mon, 14 Nov 2016 16:31:06 +0100")
Michael J Gruber <git@drmicha.warpmail.net> writes:
> *My* idea of --no-index was for it to behave as similar to the
> --index-version as possible, regarding formatting etc., and to be a good
> substitute for ordinary diff. The proposed patch achieves exactly that -
Does it? It looks to me that it does a lot more.
> why should a *file* argument (which is not a pathspec in --no-index
> mode) not be treated in the same way in which every other command treats
> a file argument? The patch un-breaks the most natural expectation.
I think a filename given as a command line argument, e.g. <(cmd), is
now treated more sensibly with [2/2]. Something that is not a
directory to be descended into and is not a regular file needs to be
made into a form that we can use as a blob, and reading it into an
in-core buffer is a workable way to do so.
However, when taken together with [1/2], doesn't the proposed patch
"achieves" a lot more than "exactly that", namely, by not treating
symbolic links discovered during traversals of directories given
from the command line as such and dereferencing?
next prev parent reply other threads:[~2016-11-14 18:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-11 20:19 [RFC/PATCH 0/2] git diff <(command1) <(command2) Dennis Kaarsemaker
2016-11-11 20:19 ` [PATCH 1/2] diff --no-index: add option to follow symlinks Dennis Kaarsemaker
2016-11-11 20:19 ` [PATCH 2/2] diff --no-index: support reading from pipes Dennis Kaarsemaker
2016-11-11 21:27 ` [RFC/PATCH 0/2] git diff <(command1) <(command2) Junio C Hamano
2016-11-11 23:14 ` Jacob Keller
2016-11-12 10:08 ` Johannes Schindelin
2016-11-14 3:14 ` Junio C Hamano
2016-11-14 15:31 ` Michael J Gruber
2016-11-14 16:40 ` Johannes Schindelin
2016-11-14 18:01 ` Junio C Hamano [this message]
2016-11-14 20:23 ` Michael J Gruber
2016-11-14 21:10 ` Junio C Hamano
2016-11-16 9:50 ` Johannes Schindelin
2016-11-16 18:29 ` Junio C Hamano
2016-11-16 18:37 ` Junio C Hamano
2016-11-12 6:11 ` Dennis Kaarsemaker
2016-11-12 7:06 ` Jeff King
2016-11-11 23:15 ` Jacob Keller
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqoa1ix7nq.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=dennis@kaarsemaker.net \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=jacob.keller@gmail.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).