From: Ben Boeckel <mathstuf@gmail.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: git@vger.kernel.org
Subject: Re: Cannot checkout after setting the eol attribute
Date: Tue, 22 Aug 2017 15:44:41 -0400 [thread overview]
Message-ID: <20170822194441.GA25093@megas.kitware.com> (raw)
In-Reply-To: <20170822191318.GA22118@tor.lan>
On Tue, Aug 22, 2017 at 21:13:18 +0200, Torsten Bögershausen wrote:
> When you set the text attribute (in your case "eol=crlf" implies text)
> then the file(s) -must- be nomalized and commited so that they have LF
> in the repo (technically speaking the index)
This seems like a special case that Git could detect and message about
somehow.
> This is what is written about the "eol=crlf" attribute:
> This setting forces Git to normalize line endings for this
> file on checkin and convert them to CRLF when the file is
> checked out.
> And this is what is implemented in Git.
Yeah, I read the docs, but the oddities of reset not doing its job
wasn't clear from this sentence :) .
> Long story short:
>
> The following would solve your problem:
> git init
> echo $'dos\r' > dos
> git add dos
> git commit -m "dos newlines"
> echo "dos -crlf" > .gitattributes
> git add .gitattributes
> git commit -m "add attributes"
> echo "dos eol=crlf" > .gitattributes
> git read-tree --empty # Clean index, force re-scan of working directory
The fact that plumbing is necessary to dig yourself out of a hole of the
`eol` attribute changes points to something needing to be changed, even
if it's only documentation. Could Git detect this and message about it
somehow when `git reset` cannot fix the working tree? Or maybe it could
at least exit with failure instead of success?
--Ben
next prev parent reply other threads:[~2017-08-22 19:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-22 17:49 Cannot checkout after setting the eol attribute Ben Boeckel
2017-08-22 19:13 ` Torsten Bögershausen
2017-08-22 19:44 ` Ben Boeckel [this message]
2017-08-23 19:43 ` Torsten Bögershausen
2017-08-23 21:09 ` Ben Boeckel
2017-08-22 20:03 ` Junio C Hamano
2017-08-23 21:17 ` [PATCH] Documentation: mention that `eol` can change the dirty status of paths Ben Boeckel
2017-08-23 21:21 ` Ben Boeckel
2017-08-24 5:50 ` Torsten Bögershausen
2017-08-30 13:49 ` Ben Boeckel
2017-08-30 21:31 ` Junio C Hamano
2017-08-31 13:16 ` Ben Boeckel
2017-08-30 13:59 ` [PATCH v2] " Ben Boeckel
2017-08-31 13:19 ` [PATCH v3] " Ben Boeckel
2017-08-31 14:33 ` Torsten Bögershausen
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=20170822194441.GA25093@megas.kitware.com \
--to=mathstuf@gmail.com \
--cc=git@vger.kernel.org \
--cc=tboegi@web.de \
/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.