Re: [PATCH 5/5] git-diff.txt: fix ordering of the [--no-index] form

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Apr 24, 2013, 20:37 UTC
Message-ID: <20130424203732.GJ29963@google.com>
In-Reply-To: <CALkWK0=KWu3=j5sLK3hr=Gx5xLnLaPAY+E=J0_izRCj9YcBTEg@mail.gmail.com>

Ramkumar Ramachandra wrote:

> Jonathan Nieder wrote:

Show 9 quoted lines

>> Because typing paths does not make my intent perfectly clear.
>
> I'm not able to understand this.  Doesn't your prompt tell you which
> directory you're in, and if you're in a git repository?  When you type
> out paths, you know what is inside and what is outside your
> repository.  By extension, you know when --no-index is implied and
> when it isn't.
>
> Can you explain what your problem is?

Are you wondering why I use --no-index or why I think we should eventually stop moving into --no-index mode by default?

The answers are different. I use --no-index because it means I don't have to think about whether the files I am comparing are in a Git repository. It's relaxing. I'm not advocating that you follow suit; I'm just describing my own usage of the command.

I think git should eventually stop doing --no-index implicitly because it is a very different mode using the same syntax triggered by external conditions. That is

 * hard to document
 * problematic for scripts calling "git diff", can create lurking bugs
 * unnecessarily complicated.  For example:
   * "git diff -h" output depends on whether I am in a git worktree.
   * git searches for a .git directory, possibly hitting filesystem
     automount points, just to decide whether its arguments are inside
     the current repository.