git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: Mr&Mrs D <the.ubik@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: Bug in lineendings handling that prevents resetting checking out, rebasing etc
Date: Fri, 14 Dec 2018 22:32:46 +0100	[thread overview]
Message-ID: <20181214213246.GA2182@tor.lan> (raw)
In-Reply-To: <CABRG_PEy9H7za9cTdXMvFB37GfDvpBvsDDoLZ5-Bpm=9NWzLiw@mail.gmail.com>

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@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
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!

  parent reply	other threads:[~2018-12-14 21:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-14 21:04 Bug in lineendings handling that prevents resetting checking out, rebasing etc Mr&Mrs D
2018-12-14 21:21 ` John Passaro
2018-12-14 21:32   ` Mr&Mrs D
2018-12-14 21:32 ` Torsten Bögershausen [this message]
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=20181214213246.GA2182@tor.lan \
    --to=tboegi@web.de \
    --cc=git@vger.kernel.org \
    --cc=the.ubik@gmail.com \
    /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).