Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 25, 2016, 11:54 UTC
Message-ID: <alpine.DEB.2.20.1608251343300.4924@virtualbox>
In-Reply-To: <xmqq37luru7z.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On Wed, 24 Aug 2016, Junio C Hamano wrote:

Show 15 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> In any case, in the ideal future, I would imagine that we would want
> >> to have "cat-file blob" to enable "--filters" by default; that would
> >> make cat-file and hash-objects a pair of symmetric operations.
> >
> > I would advocate against that. It is not like the terms "hash-object" and
> > "cat-file" even *look* like they are opposites.
> 
> I do not quite understand your objection.
> 
> hash-object is "I have data somewhere on the filesystem, and I want
> to store it in the object store even though I am not ready to add it
> to the index yet (or I may not even add it to the index ever), just
> to make it available to Git tools".

That is not how I read it. I read "hash-object" as: "hash this object". There was not a thought in my mind that it would apply filters. Since that was so clear in my mind, I failed to understand that you do not consider it a design mistake to turn on --filters by default in hash-object.

I read "cat-file" just the same: concatenate files and print on the standard output. Now, it is confusing enough that it does not concatenate files in unless in batch mode, and it would be even more confusing if it started to behave as if the user had called "git checkout --dry-run <revision> -- <path>" (which does not exist, but for which I would understand the --filters default).

> Yes, correcting ancient mistakes is costly.  Such is life.

I was not talking about the cost of correcting mistakes. Running --filters is potentially very costly. Just so you understand what I am talking about: I have a report that says that checking out a sizeable worktree with core.autocrlf=true is 58% slower than with core.autocrlf=false. That is horrible. And it is a cost that is entirely born by Windows users.

In short: I think letting hash-object default to --filters was a mistake, and doing the same for cat-file would be a mistake, too.

Ciao, Dscho