From: Florian Aspart <florian.aspart@gmail.com>
To: John Keeping <john@keeping.me.uk>
Cc: Michael J Gruber <git@drmicha.warpmail.net>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: Using clean/smudge filters with difftool
Date: Fri, 19 Jun 2015 17:04:03 +0200 [thread overview]
Message-ID: <CAGA3+++uZcVQdYme5H5HqayK2R6N41j1DVOndok3LVRDjcMZkQ@mail.gmail.com> (raw)
In-Reply-To: <20150619093251.GQ18226@serenity.lan>
2015-06-19 11:32 GMT+02:00 John Keeping <john@keeping.me.uk>:
> On Fri, Jun 19, 2015 at 10:57:55AM +0200, Michael J Gruber wrote:
>> Junio C Hamano venit, vidit, dixit 19.06.2015 00:55:
>> > John Keeping <john@keeping.me.uk> writes:
>> >
>> >> I think the summary is that there are some scenarios where the external
>> >> diff tool should see the smudged version and others where the clean
>> >> version is more appropriate and Git should support both options. It
>> >> seems this is a property of the filter, so I wonder if the best solution
>> >> is a new "filter.<name>.extdiff = [clean|smudge]" configuration
>> >> variable (there's probably a better name for the variable than
>> >> "extdiff").
>> >
>> > Not just the external diff, but the textconv filter obeys the same
>> > rule. The setting should be done the same way for both, if we are
>> > going to go in that direction.
>> >
>>
>> textconv is a "one-way" filter from "blob" to "readable blob". External
>> diffs may prefer to work on "blob" rather than "readable blob", but the
>> currect setup does not seem to produce surprises.
>>
>> clean and smudge are two-way filters: clean from "worktree blob" (aka
>> file) to "repo blob", smudge the other way round.
>>
>> Typically, the user perceives these as inverse to each other. But we
>> only require clean to be a left-inverse of smudge, i.e. "(cat-file then)
>> smudge then clean" should give the same "repo blob" (as "cat-file").
>>
>> We don't require that the other way round, i.e. we don't require smudge
>> to be a left-inverse of clean, and in most setups (like the current one)
>> it is not: smudge does not recreate what clean has cleaned out. It is a
>> no-op (the "identity", while clean is a "projection").
>>
>> Now, since external diff runs on smudged blobs, it appears as if we
>> mixed cleaned and smudged blobs when feeding external diffs; whereas
>> really, we mix "worktree blobs" and "smudged repo blobs", which is okay
>> as per our definition of clean/smudge: the difference is irrelevant by
>> definition.
>
> I agree with this.
>
> But I was wrong that "should diff clean"/"should diff smudged" is a
> property of the filter. I can also imagine a situation where a more
> intelligent external diff tool wants to see the smudged version where a
> naïve tool would want the clean version.
>
> For example, some of the big file stores (e.g. git-lfs [1]) use
> clean/smudge filters and I can imagine a diff utility that avoids
> needing to fetch the data for large files and instead shows the diff on
> the server when both blobs are available there. In that case we
> generally want to use the smudged copy for external diff, so the filter
> would use that setting, but the diff utility knows better and would want
> to override that.
>
> [1] https://github.com/github/git-lfs
I can understand why they are not fed with the clean copy by default.
Since some external diff tool enable modifying the working copy file,
this would correspond to apply the cleaning filter to the working copy
version.
Nevertheless, in my case it would be really helpful if there were an
option to feed the external diff tool with the cleaned version.
Otherwise, I'll probably write a custom script which does this.
next prev parent reply other threads:[~2015-06-19 15:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 14:11 Using clean/smudge filters with difftool Florian Aspart
2015-06-18 12:31 ` Michael J Gruber
2015-06-18 13:15 ` Florian Aspart
2015-06-18 13:26 ` John Keeping
2015-06-18 13:51 ` Florian Aspart
2015-06-18 14:11 ` John Keeping
2015-06-18 14:17 ` Florian Aspart
2015-06-18 14:28 ` John Keeping
2015-06-18 15:39 ` Florian Aspart
2015-06-18 16:01 ` John Keeping
2015-06-18 20:00 ` Junio C Hamano
2015-06-18 22:39 ` John Keeping
2015-06-18 22:55 ` Junio C Hamano
2015-06-19 8:57 ` Michael J Gruber
2015-06-19 9:32 ` John Keeping
2015-06-19 15:04 ` Florian Aspart [this message]
2015-06-19 17:03 ` Junio C Hamano
2015-06-21 19:29 ` Michael J Gruber
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=CAGA3+++uZcVQdYme5H5HqayK2R6N41j1DVOndok3LVRDjcMZkQ@mail.gmail.com \
--to=florian.aspart@gmail.com \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=john@keeping.me.uk \
/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.