All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: "Randall S. Becker" <rsbecker@nexbridge.com>
Cc: "'Jeff King'" <peff@peff.net>, <git@vger.kernel.org>
Subject: Re: [Question] Diff text filters and git add
Date: Thu, 11 Jul 2019 19:28:29 +0200	[thread overview]
Message-ID: <86h87sa3b6.fsf@gmail.com> (raw)
In-Reply-To: <00bb01d5371d$453a8520$cfaf8f60$@nexbridge.com> (Randall S. Becker's message of "Wed, 10 Jul 2019 08:44:47 -0400")

"Randall S. Becker" <rsbecker@nexbridge.com> writes:
> On July 9, 2019 5:51 PM, Peff wrote:
[...]
>> No, textconv only applies when generating a diff to output, and will never
>> impact what's stored in Git.
>> 
>> It sounds like you might want a clean filter instead, to sanitize the file
>> contents as they come into Git (and perhaps a matching smudge filter to
>> convert back to the working-tree version if necessary).
>> 
>> You're talking about "the diff engine" here, but note that git-add would never
>> do a diff at all. It cares only about full sha1s (and optimizes out re-computing
>> the sha1 on each invocation by using stat data). So outside of clean/smudge,
>> there's nothing else going on.
>
> Thanks. I can script this instead. Will do an external diff then
> --assume-unchanged when I detect an equivalence.

If you want to ignore changes, --assume-unchanged (i.e. lying to Git) is
a wrong solution, as it can lead to data loss.  It is meant as
performance optimization.

A better solution would be to use --skip-worktree, which though meant
for sparse checkout can be used for ignoring changes.  The only problem
is that it can prevent some safe operations, like git-stash, because git
thinks that it could lead to data loss.

Though I am not sure if they are needed with clean/smudge filter.

Best,
-- 
Jakub Narębski

      reply	other threads:[~2019-07-11 17:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-09 21:43 [Question] Diff text filters and git add Randall S. Becker
2019-07-09 21:51 ` Jeff King
2019-07-10 12:44   ` Randall S. Becker
2019-07-11 17:28     ` Jakub Narebski [this message]

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

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

  git send-email \
    --in-reply-to=86h87sa3b6.fsf@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=rsbecker@nexbridge.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.