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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 24, 2016, 15:48 UTC
Message-ID: <alpine.DEB.2.20.1608241743460.4924@virtualbox>
In-Reply-To: <xmqqbn0iu50a.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On Tue, 23 Aug 2016, Junio C Hamano wrote:

Show 10 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > The feature in question is also highly unlikely to be used as much by
> > non-Windows users as by Windows users due to the unfortunate choice of the
> > default setting for core.autocrlf.
> 
> My vague recollection from some years ago was that even among those
> who were active in msysGit development there were people who
> advocated for straight-thru and others who wanted core.autocrlf as
> the default, but I do not know the current state of the affairs.

I remember this very non-vaguely, for I was one of the people advocating straight-through. I basically was shot down by people using Windows more regularly than I did.

In any case, now is not the time to lament about this.

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

The main problem you face with making --filters the default is that it is a possibly costly switch. Too costly in my opinion, just think of git-lfs.

> That certainly will not happen within 2.x timeframe, and the new
> "cat-file --filter" feature can appear in 2.11 at the earliest, but

s/--filter/--filters/

Show 10 quoted lines

> I think by that time (or with a few more cycles) we may have a
> handful other improvements that are backward incompatible lined up
> to urge us to think about bumping the version number to 3.0.  I
> recall writing "Will keep in next to see if anybody screams" a few
> times already, and they are all good excuses to invite a version
> bump.
> 
> To prepare for that future, we would probably want to start updating
> in-tree scripts (including the tests) so that they call "cat-file
> --no-filter blob" whereever they currently say "cat-file blob" in or

s/--no-filter/--no-filters/

> soon after 2.11.  Of course, if some of them currently pipe
> "cat-file blob" output to munge it to produce what --filters would
> have done (I didn't check), we would want to rewrite them to use the
> new feature "cat-file --filter blob" when we do so.  In short, there

s/--filter/--filters/

Show 5 quoted lines

> won't be any "cat-file blob" call that does not have either --filters
> or --no-filters, except the ones we write specifically to check the
> updated default behaviour when that happens.
> 
> Would that sound like a good longer-term plan?

Apart from my objecting against changing the default of cat-file, it sure sounds like a good long-term plan ;-)

Ciao, Dscho