CRLF behavior

I'm running MSYSgit on Windows, and have no mention of any kind of crlf conversion in the config files.  Running git config --list shows nothing that would suggest any such setting.  So, my autocrlf is "unspecified" which according to the docs defaults to false, which means "don't mess with it", right?

A co-worker got a autocrlf=true set when some git tool was updated, and made a mess before it was noticed.

Now, looking at one commit for example, I see a file in it that reports all lines have changed.  Clearly it's checked in with LF's, and gitk will make it go away if I check the "ignore whitespace" box.  The "external diff" (kdiff3) reports "text is the same but files are not binary identical".  So far, so good.

But if I check out his commit, I see files with CRLF endings.  Why is it doing that?  I had to spy on the temp files used by the diff tool in order to see the LF line endings.  So it seems able to cough up a proper exact copy, but normally changes it during a checkout operation.

I get mysterious things like after checking out, it immediately says I have a bunch of files changed.  Or, it didn't show any; and after saving one file (no actual change) and rescanning, I had 5 files "changed".  I'm guessing it is getting confused because sometimes it sees the internal representation and sometimes it sees the translated representation.

What's going on?

--John

(sorry about the footer)

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

On Wed, Jul 21, 2010 at 5:18 PM, John Dlugosz <JDlugosz@tradestation.com> wrote:

Try 'git config --global --list'

Avery

I thought that --list tells me the sum result of all the settings in force; i.e. the final result that should be used here and now.

I get:  fatal: $HOME not set

Trying again from the "git bash here" shell, I see there is a core.autocrlf=true !

I see it is set in %APPDATA%\..\.gitconfig, which is where MINGW likes to put its per-user data (one level higher than it should be; Unix doesn't distinguish the appdata from the user files so it put it all one level higher where nobody knows to look!)

So, assuming it's been that way (the file is dated March), what's the repository "really" doing?  When things started acting funny, my co-worker found this setting and removed it from his.  If that's not it, I can only wonder why it started showing all-lines-changed ?

--John

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

On Wed, Jul 21, 2010 at 5:35 PM, John Dlugosz <JDlugosz@tradestation.com> wrote:

Sadly not.

Yow, that's kind of bad news.  It implies that if you run git from one
shell, it will be able to find your global .gitconfig (and thus use
autocrlf), but if you run it from a different kind of shell, it won't.
 This could be the root of your problem.

One "solution" would be to change git to always die immediately if $HOME isn't set.

I don't know. One thing I do know is that changing the autocrlf setting on an active repository makes git go bonkers and there's no (as far as I know) well-documented way to un-bonkers it other than to just check out everything again.

If your problem really is that the ~/.gitconfig comes and goes (as far as git is concerned), it could certainly have caused this problem.

Have fun,

Avery

On Wed, Jul 21, 2010 at 5:51 PM, Avery Pennarun <apenwarr@gmail.com> wrote:

It take it back: it does do this. But if $HOME isn't set, apparently it silently fails to read $HOME/.gitconfig and uses a different set of options. Just confirmed this myself, and it's true. This probably should be considered a serious bug.

Avery

The "git bash here" launches a copy of CMD.exe (the brain-dead Windows shell that's descendant from COMMAND.COM) with a command line that tells it to run sh.exe --login -i.

I see that neither the CMD process nor the sh.exe process contains a HOME environment variable.  So, the $HOME reported within bash is something that bash itself came up with based on Windows settings, and was not set before running it.

The wish.exe running git-gui _does_ contain a HOME environment variable, set to a natural Windows path.  It also contains others, such as GIT_DIR that contains the current repository it was started for, as a Windows drive-letter-path but with Unix-style slashes, and GIT_ASK_YESNO.  Presumably these were set as part of the machinery that launched the program from the context menu in explorer.  I don't see how it's being launched -- it does not show up in Autoruns (from Sysinternals).

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Running from the Windows console window, I get an error about HOME with --global.  From the "git bash here" prompt, doing 'git config --list' by itself shows more settings, including autocrlf=true.  IOW, it finds the global settings and merges them.

So, perhaps sometimes git sees the setting and sometimes it doesn't?  Doing 'checkout' from the command line might behave differently from git gui or some other Windows extension.

I don't know how msysgit called from some random process is supposed to set up environment variables for it?  I would think that the UNIX-like $HOME, which shows as some translated cygwin path from the git bash shell, should be set up automatically based on the Windows "special folders" as part of the MSYS stuff.

The "git gui" program, which is actually wish.exe, appears to have been invoked as:

	"C:\Program Files (x86)\Git\bin\wish.exe"  "C:\Program Files (x86)\Git\libexec\git-core\git-gui" "--working-dir" "D:\work\ORCAL\SCM\Dev"

Is there a way to tell from within git-gui or kgit whether it is finding that settings file?  I think that git-gui calls git.exe to do the work, just like I can call directly and presumably other extensions and tools do.

Is there a way to tell what's "really" in the repository, for a commit that pre-dates any trouble?

--John

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

On Wed, Jul 21, 2010 at 05:18:07PM -0400, John Dlugosz wrote:

msysgit has default core.autocrlf=true

- Finn Arne

Do you mean that's the value it assumes if no entry was found in the file?  That does not match what was happening.

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.