From: "Mr&Mrs D" <the.ubik@gmail.com>
To: git <git@vger.kernel.org>
Subject: Bug in lineendings handling that prevents resetting checking out, rebasing etc
Date: Fri, 14 Dec 2018 16:04:15 -0500 [thread overview]
Message-ID: <CABRG_PEy9H7za9cTdXMvFB37GfDvpBvsDDoLZ5-Bpm=9NWzLiw@mail.gmail.com> (raw)
Hi all,
I maintain a python project you can clone from:
git@github.com:wrye-bash/wrye-bash.git
For reasons unknown git sees a particular file as changed
(Mopy/Docs/Bash Readme Template.html, sometimes others too). This file
was probably committed to the svn repository this git repo was created
from with CRLF line endings. When we moved to git we added a
gitattributes file (
https://github.com/wrye-bash/wrye-bash/blob/dev/.gitattributes ) and
this file was edited to explicitly state htms are text - all to no
avail. From time to time - on windows - as in when checking out an old
commit - git would see that file as changed. The only workaround that
worked for me was
git rm -r . --cached -q && git reset --hard
For more details and discussion see this SO question I posted almost
five years ago:
https://stackoverflow.com/questions/21122094/git-line-endings-cant-stash-reset-and-now-cant-rebase-over-spurious-line-en
I used to work in windows and the bug was tolerable as there was that
workaround. Now I moved to mac and no workaround works anymore - we
have a special page on our wiki with workarounds for this one btw:
https://github.com/wrye-bash/wrye-bash/wiki/%5Bgit%5D-Issues-with-line-endings-preventing-checking,-merge,-etc
Well after 5 years and countless hours trying to solve this I reach
out to you guys and girls - _this is a full-time bug in git line
endings handling_. When someone issues a git reset --hard this should
work no matter what - well it does not. So this bug may be really a
can of worms.
Please someone clone this repo on linux or mac - probably just cloning
will have the files appear as changed (by the way hitting refresh on
git gui I have different sets of files appear as changed). If not then
git checkout utumno-wip
git rebase -i dev
and then select a commit to edit should be enough to trigger this bug
Needless to say I am well aware of things like `git add --renormalize
.` - but renormalizing is not the issue. The issue is that _files show
as changed and even a git reset --hard won't convince git that
nothing's changed_.
$ git reset --hard
HEAD is now at e5c16790 Wip proper handling of ini tweaks encoding - TODOs:
$ git status
interactive rebase in progress; onto 02ae6f26
Last commands done (4 commands done):
pick 3a39a0c0 Monkey patch for undecodable inis:
pick e5c16790 Wip proper handling of ini tweaks encoding - TODOs:
(see more in file .git/rebase-merge/done)
Next commands to do (19 remaining commands):
edit a3a7b237 Amend last commit and linefixes: ΕΕΕΕ
edit 432fd314 fFF handle empty or malformed inis
(use "git rebase --edit-todo" to view and edit)
You are currently editing a commit while rebasing branch 'utumno-wip'
on '02ae6f26'.
(use "git commit --amend" to amend the current commit)
(use "git rebase --continue" once you are satisfied with your changes)
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: Mopy/Docs/Bash Readme Template.html
Untracked files:
(use "git add <file>..." to include in what will be committed)
.DS_Store
.idea.7z
no changes added to commit (use "git add" and/or "git commit -a")
$
I really hope someone here can debug this
Thanks!
next reply other threads:[~2018-12-14 21:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-14 21:04 Mr&Mrs D [this message]
2018-12-14 21:21 ` Bug in lineendings handling that prevents resetting checking out, rebasing etc John Passaro
2018-12-14 21:32 ` Mr&Mrs D
2018-12-14 21:32 ` Torsten Bögershausen
2018-12-14 21:51 ` Mr&Mrs D
2018-12-15 4:43 ` Torsten Bögershausen
2018-12-15 20:58 ` Mr&Mrs D
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABRG_PEy9H7za9cTdXMvFB37GfDvpBvsDDoLZ5-Bpm=9NWzLiw@mail.gmail.com' \
--to=the.ubik@gmail.com \
--cc=git@vger.kernel.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).