git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Potapov <dpotapov@gmail.com>
To: Steffen Prohaska <prohaska@zib.de>
Cc: gitster@pobox.com, torvalds@linux-foundation.org, git@vger.kernel.org
Subject: Re: [PATCH] safecrlf: Add flag to convert_to_git() to disable safecrlf check
Date: Tue, 15 Jan 2008 13:26:26 +0300	[thread overview]
Message-ID: <20080115102626.GE2963@dpotapov.dyndns.org> (raw)
In-Reply-To: <12003528401309-git-send-email-prohaska@zib.de>

On Tue, Jan 15, 2008 at 12:20:40AM +0100, Steffen Prohaska wrote:
> 
> I looked briefly at the various places where convert_to_git() is
> called.  I think that only the one code path through index_fd()
> actually writes data to the repsitory.  Maybe someone else with
> a better understanding of git's internals should confirm this.

Your patch is certainly better than my quick hack for git-add,
and perhaps you are right that the check should be done only
when data are written, but it also means that there is no longer
any warning when you are running git diff with the work tree,
which would be useful, because it is what most users do before
adding anything.

However, my real concern is that it seems we have two different
heuristics for binary -- one that is used inside of convert.c
and the other one is buffer_is_binary() in xdiff-interface.c.

So, I am running 'git diff' for some test file, and it says:

diff --git a/foo b/foo
index e965047..c102bdc 100644
Binary files a/foo and b/foo differ

okay, now I want to add this *binary* file, so I run 'git add':

warning: Stripped CRLF from foo.

I imagine a user saying: "What the hell! Why did this stupid Git
strip CRLF from my _binary_ file?"

And the current version of Git, which does not print CRLF warning,
seems to be dangerous, because when 'git diff' told me that it is
a _binary_ file, I expect that Git will put it as *binary*. So,
from the user's point of view, it looks like a bug.

So, I suppose that at least we should make is_binary heuristic in
convert.c more strict than those that is used by diff. Namely, if
there is at least one NUL byte in the buffer, it should be treated
as binary.


Dmitry

  parent reply	other threads:[~2008-01-15 10:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-13 16:30 [PATCH v3] safecrlf: Add mechanism to warn about irreversible crlf conversions Steffen Prohaska
2008-01-13 22:02 ` Dmitry Potapov
2008-01-13 22:13 ` Dmitry Potapov
2008-01-13 23:46 ` [PATCH] Don't display crlf warning twice Dmitry Potapov
2008-01-14  6:17   ` Steffen Prohaska
2008-01-14  6:40     ` Dmitry Potapov
2008-01-14  6:53       ` Steffen Prohaska
2008-01-14 23:20         ` [PATCH] safecrlf: Add flag to convert_to_git() to disable safecrlf check Steffen Prohaska
2008-01-14 23:58           ` Junio C Hamano
2008-01-15 20:52             ` Steffen Prohaska
2008-01-15 21:41               ` Steffen Prohaska
2008-01-15 23:23                 ` Junio C Hamano
2008-01-15 10:26           ` Dmitry Potapov [this message]
2008-01-15 20:39             ` Steffen Prohaska
2008-01-15 23:03               ` Dmitry Potapov

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=20080115102626.GE2963@dpotapov.dyndns.org \
    --to=dpotapov@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=prohaska@zib.de \
    --cc=torvalds@linux-foundation.org \
    /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).