From: Junio C Hamano <gitster@pobox.com>
To: Sebastian Schuberth <sschuberth@gmail.com>
Cc: Jeff King <peff@peff.net>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org
Subject: Re: [PATCH] Respect core.autocrlf when preparing temporary files for external diff
Date: Sun, 22 Mar 2009 14:59:07 -0700 [thread overview]
Message-ID: <7vljqxcj84.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: bdca99240903220830u50999dfcnee0f0091b4dec835@mail.gmail.com
Sebastian Schuberth <sschuberth@gmail.com> writes:
> Me being the reporter of the original msysGit issue #177, I'd like to
> clarify that my intention not necessarily was to make
> "core.autocrlf=true" affect temporary files (i.e. to "smudge" them),
> but to ensure that the files fed into "git diff" are always generated
> / acquired in a consistent way, so that they are in fact comparable.
Thanks. I think everybody involved in the thread is in agreement with
that.
> I'd also be happy with a solution that always feeds clean files into
> "git diff", although that would probably mean that we could not reuse
> working tree files if "core.autocrlf=true" is set.
When we generate diff internally, even when we borrow from the work tree,
we clean it before using. See diff_populate_filespec(), ll.1900-1915.
Borrowing done by diff_tempfile(), which currently does not run clean, and
the call to prep_temp_blob() in ll.2030-2035 that gives a temporary file
without convert_to_working_tree() are inconsistent, as pointed out by you
and Dscho.
If you run "git diff <filename>" after cloning, I expect that no temporary
files are involved, _unless_ you have some settings that force "git diff"
not to use the internal diff. Do you use GIT_EXTERNAL_DIFF? Do you use
"textconv" attribute? What external program do you invoke from these
mechanisms, and what does it expect to see as its input?
The discussion in the last few messages in this thread speculates that the
external programs are more likely to expect representations suitable in
the work tree, aka "smudged", than "clean" one. It would be nice to get a
datapoint from you as the original reporter to confirm or refute that
speculation.
next prev parent reply other threads:[~2009-03-22 22:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1237635609u.git.johannes.schindelin@gmx.de>
2009-03-21 11:42 ` [PATCH] Respect core.autocrlf when preparing temporary files for external diff Johannes Schindelin
2009-03-21 17:02 ` Michael J Gruber
2009-03-21 19:35 ` Junio C Hamano
2009-03-21 23:54 ` Johannes Schindelin
2009-03-22 0:03 ` Junio C Hamano
2009-03-22 0:41 ` Junio C Hamano
2009-03-22 6:10 ` Jeff King
2009-03-22 7:18 ` Junio C Hamano
2009-03-22 7:46 ` Jeff King
2009-03-22 15:30 ` Sebastian Schuberth
2009-03-22 21:59 ` Junio C Hamano [this message]
2009-03-22 22:48 ` Sebastian Schuberth
2009-03-22 23:12 ` Junio C Hamano
2009-03-23 0:39 ` Junio C Hamano
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=7vljqxcj84.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sschuberth@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.
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 NNTP newsgroup(s).