Hi Junio, On Tue, 23 Aug 2016, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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/ > 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/ > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html