Thanks for looking to it - git attributes was added in 4b0863a8b834c5804fd3a568ed56ff85b27acdeb The file in question was added in 17ca75f0a8c25f321f2b63bc3b9c065ff91adc23 So you mean to say that because a gitattributes was added after the fact this resulted in an illegal state? But _shouldn't git reset --hard work anyway?_ That's the buggy part. As for fixing it - not sure what is the best course of action here. probably issuing `git add --renormalize .` and committing that to the stable (dev) branch will fix this for future checkouts/rebases but IIUC won't do nothing for older commits - so checking out a commit before the fix one, ghit will see this file as changed and then completely refuse to go back to another branch This seems a bug - as illegal as the state of the file is, shouldn't git reset always work? Thanks! (will be out for a bit but really looking forward to your replies) On Fri, Dec 14, 2018 at 4:32 PM Torsten Bögershausen <tboegi@xxxxxx> wrote: > > On Fri, Dec 14, 2018 at 04:04:15PM -0500, Mr&Mrs D wrote: > > 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 > Thet commit is -excuse me if that sounds too harsh- is messed up. > git status says > modified: Mopy/Docs/Bash Readme Template.html > > And if I dig into the EOL stuff, I run > git ls-files --eol | grep Readme | less > > And find a contradiction here: > i/crlf w/crlf attr/text Mopy/Docs/Bash Readme Template.html > > The attributes say "text" and the file has CRLF "in the repo", > (techically speaking in the index) and that is an "illegal" condition > in the repo, and not a bug in Git. > I didn't try the rebase as such, sice the first problem needs > to be fixed, before we try to move on. > > So, the old commits are problematic/illegal and they are as they are. > Such a commit can not be fixed, whenever somebody checks it out, > there will be a problem (or two, or none, depending on the timing, > the file system...) > > We can not fix commits like b1acc012878c9fdd8b4ad610ce7eae0dcbcbcab0. > We can make new commits, and fix them. > > We can fix one branch, and other branches, and merge them together. > But rebase seems to be problamatic, at least to me. > What exactly do you want to do? > > Can we agree to do a merge of 2 branches? > Then I can possibly help you out. > > > > > > > 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!
