Re: core.autocrlf & Cygwin - files incorrectly flagged as modified

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

 



Tay Ray Chuan writes:
> On Wed, Dec 16, 2009 at 6:24 AM, David Antliff wrote:
> > I suspect what is happening is that the line conversion routine in git
> > might be
> > stripping trailing whitespace, as well as converting the line endings. This
> > operation is not properly accounted for in the reverse direction, and the
> > file is flagged as modified.
> 
> I am not a Git expert, but could it be your editor on Windows?

Hi Ray, thank you for responding.

This observation is made immediately after the clone, before any editor (or any
other program) even touches the files. If you can imagine doing a fresh clone
and then immediately doing 'git-status' and seeing modified files, you'd have a
pretty good idea of what I'm seeing. Git itself has somehow marked the files as
modified on check-out. I am fairly certain it's related to trailing whitespace
on one or more lines within the affected files.

If there's no trailing whitespace, git converts the file to CRLF on checkout
and shows no modification (since it knows to convert back when referring to
local repository).

> > Also, as cloned files are converted to DOS-line-endings, by default Cygwins
> > bash cannot run any scripts as they have the wrong line endings. I have to 
> > set the 'permanent' bash variable SHELLOPTS to include 'igncr' before bash
> > scripts can run. Perhaps this is wrong and git on Cygwin (with binary 
> > mounts) should be converting to UNIX line endings instead?
> 
> Again, IANAGE, but according to the manual, this should be expected,
> because Git, when writing to the filesystem, converts LF to CRLF:
> 
>   If true, makes git convert CRLF at the end of lines in text files to
>   LF when reading from the filesystem, and convert in reverse when
>   writing to the filesystem.

Yes, perhaps the advice to use autocrlf=true on Cygwin (in binary mount mode,
since in text mode git doesn't work *at all*) is misplaced since Cygwin is not
expecting CRLF endings in that mode. Apparently it's required for apps like
Kdiff3 however... all so confusing really...

The inability to run bash scripts straight out of git when using autocrlf=true
is almost enough to suggest to me that this mode really shouldn't be used in
Cygwin.
 
> > At one point I tried switching off core.autocrlf for myself but this
> > caused a lot of conflicts due to mismatched line-endings. It seems to me
> > that if we want to switch to this, *everyone* has to do it at once.
> 
> Just make this conversion a commit, and depending on your project's
> workflow, push/pull it.

Yes, I think that's how it has to be done. Unfortunately I have 20+ projects
each with many active branches. The entire conversion is possible but it's
going to take a while... :)

> Although the whole file will be marked as changed, you can always
> double-check that only whitespace changes have been made by running
> git-diff with --ignore-space-at-eol or -b.

That's a helpful option - thank you.


I'd be quite interested to know if people are successfully using git in Cygwin
with autocrlf=true, and if so how they are working around these modified-files
and bash-compatibility problems.

Also, is anyone using autocrlf=false in Cygwin successfully?

Thanks again for your reply.

-- David.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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]