From: Jens Lehmann <Jens.Lehmann@web.de>
To: Jeff King <peff@peff.net>
Cc: Brad King <brad.king@kitware.com>,
git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH 2/2] submodule: Tolerate auto/safecrlf when adding .gitmodules
Date: Thu, 21 Jun 2012 21:06:28 +0200 [thread overview]
Message-ID: <4FE370B4.60404@web.de> (raw)
In-Reply-To: <20120620191132.GB31520@sigill.intra.peff.net>
Am 20.06.2012 21:11, schrieb Jeff King:
> The only sane thing is to have a canonical in-repo representation.
> Fortunately we already have the infrastructure for that, and in theory
> it should be as easy as adding ".gitmodules text" to our built-in
> gitattributes (you could even do "eol=lf", but I don't see a reason not
> to respect the native line endings in the working tree, given that git
> can handle the CRLFs just fine).
>
> I say "in theory" there because I am not sure whether specifying a file
> as definitely text via attributes will actually suppress the safecrlf
> check or not. IMHO, it should, since safecrlf is really about preventing
> false positives via autocrlf or text=auto.
A quick test shows that unfortunately theory differs from practice here.
Adding ".gitmodules text" to the built-in gitattributes lets the test
Brad wrote still fail. You have to use ".gitmodules eol=lf" to make it
pass. I stopped digging deeper at this point.
> I don't see any reason for each individual repo to have to add these
> attributes manually. This is a git-specific file, and the format is
> dictated by git. We know that it's a text file, so why not help out the
> user? We should possibly do the same thing for .gitattributes and
> .gitignore.
I really like this approach. (And in the long run would like to see a
ini-file aware merge driver being used for the .gitmodules file too,
which would just merge submodules added in different branches instead
of producing a conflict)
next prev parent reply other threads:[~2012-06-21 19:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-20 14:43 [PATCH 0/2] submodule add + autocrlf + safecrlf Brad King
2012-06-20 14:43 ` [PATCH 1/2] submodule: Demonstrate failure to add with auto/safecrlf Brad King
2012-06-20 14:43 ` [PATCH 2/2] submodule: Tolerate auto/safecrlf when adding .gitmodules Brad King
2012-06-20 17:52 ` Jens Lehmann
2012-06-20 18:06 ` Brad King
2012-06-20 18:21 ` Jens Lehmann
2012-06-20 19:11 ` Jeff King
2012-06-20 19:53 ` Junio C Hamano
2012-06-21 19:06 ` Jens Lehmann [this message]
2012-06-20 17:49 ` [PATCH 0/2] submodule add + autocrlf + safecrlf Junio C Hamano
2012-06-20 18:09 ` Brad King
2012-06-20 19:24 ` 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=4FE370B4.60404@web.de \
--to=jens.lehmann@web.de \
--cc=brad.king@kitware.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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.