Bug in lineendings handling that prevents resetting checking out, rebasing etc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I maintain a python project you can clone from:

git@xxxxxxxxxx: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!




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux