mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Michael J Gruber <>
To: Junio C Hamano <>
Cc: Johannes Schindelin <>,
	Jacob Keller <>,
	Dennis Kaarsemaker <>,
	Git mailing list <>
Subject: Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)
Date: Mon, 14 Nov 2016 21:23:07 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Junio C Hamano venit, vidit, dixit 14.11.2016 19:01:
> Michael J Gruber <> 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.

Yes, I didn't mean to say that it achieves only that - it achieves that
one goal exactly, and 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?

It's not clear to me what you are saying here - 1/2 makes git diff
follow symbolic links, yes, just like ordinary diff. If I 'diff' two
dirs that contain symbolic links with the same name pointing to
different files I get a diff between the contents, not between the

I like the proposed change a lot, maybe that didn't come across clearly.
I think it makes things more "predictable" in the sense that it meets
typical expectations.


  reply	other threads:[~2016-11-14 20:23 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
2016-11-14 20:23           ` Michael J Gruber [this message]
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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* 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

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