git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael J Gruber <git@drmicha.warpmail.net>,
	Duy Nguyen <pclouds@gmail.com>,
	git-for-windows <git-for-windows@googlegroups.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3
Date: Thu, 25 Aug 2016 13:54:41 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1608251343300.4924@virtualbox> (raw)
In-Reply-To: <xmqq37luru7z.fsf@gitster.mtv.corp.google.com>

Hi Junio,

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

> 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

  reply	other threads:[~2016-08-25 11:56 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-13 10:14 [ANNOUNCE] Git for Windows 2.9.3 Johannes Schindelin
2016-08-13 15:50 ` Junio C Hamano
2016-08-17 13:54   ` Johannes Schindelin
2016-08-17 15:29     ` Junio C Hamano
2016-08-18  8:37       ` Johannes Schindelin
2016-08-22 14:04         ` [git-for-windows] " Duy Nguyen
2016-08-23 13:54           ` Johannes Schindelin
2016-08-23 14:41             ` Michael J Gruber
2016-08-23 15:37               ` Johannes Schindelin
2016-08-23 16:05                 ` Johannes Schindelin
2016-08-23 19:25                   ` Junio C Hamano
2016-08-23 21:42                     ` Junio C Hamano
2016-08-24  1:04                       ` Dakota Hawkins
2016-08-24 15:41                         ` Git for Windows documentation, was " Johannes Schindelin
2016-08-24 16:06                           ` Dakota Hawkins
2016-08-24 23:28                             ` Philip Oakley
2016-08-25 11:42                             ` Johannes Schindelin
2016-08-24 15:39                     ` Johannes Schindelin
2016-08-24  5:09                   ` Junio C Hamano
2016-08-24 15:48                     ` core.autocrlf, was " Johannes Schindelin
2016-08-24 16:45                       ` Junio C Hamano
2016-08-25 11:54                         ` Johannes Schindelin [this message]
2016-08-25 12:43                           ` Torsten Bögershausen
2016-08-25 13:50                             ` Johannes Schindelin

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1608251343300.4924@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=git-for-windows@googlegroups.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://80x24.org/mirrors/git.git

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