Move source code into sub-directory /src

[Brett208]

Closes #4

[Brett208]

Well, I'm not sure here. I revisited this by checking the log via TortoiseGit. TortoiseGit is correctly listing all files as renames, which you can see from the attached screenshot. When I create the merge request on GitHub, GitHub seems to disagree with some of the files just being renamed.

I tried reverting back to the master branch, then repeating the operation in a new branch. I thought this should have restored the local copies of the source code to how they exist in the repository. Then I moved the files back into the src directory and committed. It appears to have done the exact same thing. Is it possible that somehow my local repository is smart enough to track whitespace changes locally as not being changes that are being reported as changes on the remote? This doesn't seem right though.

I prefer the files marked as rename in the repository since it improves tracking the file changes. However, I really don't have an appetite for slogging through the bowels of Git right now to get everything in agreement.

-Brett

[Brett208]

I'm seeing the Lines Added and Lines Removed are not 0 on a lot of the renames. GitHub is not counting them as renames if there are any line changes, which is different behavior from TortoiseGit.

I just created a fresh clone of the repository from GitHub on my computer. Then I moved the files using Windows Explorer and committed using TortoiseGit. I did not open Visual Studio at all during the process. The results were exactly the same. Whatever is happening doesn't appear to be related to Visual Studio. Not sure if Windows Explorer or TortoiseGit is applying the whitespace changes.

Also, not sure what makes TortoiseGit call them renames even though it reports the entire file changes and GitHub to not call these renames.

-Brett

[DanRStevens]

Ahh, you might have some automatic line ending conversions done by the Git client. Many are setup with automatic line ending conversion settings by default.

Additionally, some diff programs have flags to ignore whitespace changes. These might be enabled by default, or might be why your local client is not showing any changes.

I'll check in more detail a little later.

[DanRStevens]

Ok, I looked at a diff that highlighted whitespace changes. It seems there are trailing spaces or tabs on some lines that were removed. In some cases, it appears to be the auto indent tab on blank lines. In others it's whitespace after the semicolon or some trailing punctuation.

Perhaps you can run a regex search and replace on the code to find all whitespace followed by the end of line character (\s+$), and replace it with an empty string. You can run that conversion as the first commit on the branch, and then try moving the code in a second commit. If the whitespace changes are pre-done, the files will hopefully be properly marked as moved at that point.

I checked both branches, and they both have identical looking whitespace changes.

[DanRStevens]

Oh, and on a side note. I believe Git does not actually track renames in the repository with metadata. Renames are detected using heuristics. Hence the discrepancy when there are subtle changes to the file.

[Brett208]

I'm fairly certain the actual problem is Git changing line endings on commit. There is a setting to standardize line endings in Git. It is currently set to auto on my local machine and has decided to change the line endings on the files.

I don't know why it has decided it needs to change the line endings at this time. I don't know if the auto is seeing the new makefile in the repo?

There is a way to standardize line endings across the repository using a .gitattributes file if we want to pick one and go with it. https://help.github.com/articles/dealing-with-line-endings/

I did try deleting random 'hanging' spaces and tabs occuring at the end of the line, but this did not change rename status. Changing the line endings to 'do not change' in Git did fix it regardless of any of the hanging spaces or tabs existing.

Will try to upload soon.

[Brett208]

This has been replaced by Pull Request #14.

[DanRStevens]

Looks like you got it all sorted.

I have a global Git setting to ensure my client doesn't make any unexpected changes:

core.autocrlf=false

My take on it: I like the global setting better. You don't need to litter every repository with a settings file, which will no doubt be forgotten for some repo when you least expect it. Plus, the repo specific settings don't enforce a policy, they just set a default behaviour. Someone can override it if they want to. Hence, a repo setting isn't really protecting that repo from anything. Besides, these changes affect your own commits, not ones you download, so it makes sense to use settings based on how you work.

My personal taste, is to not have unexpected and unrelated changes to code in my commits. If I need a change, I can explicitly make a change. I want the power in my hands.

Anyway, thanks for cleaning this up and getting this done.

[Brett208]

I'm having major line ending problems now in OP2Utility that don't seem to be solved by setting the clrf settings in the repository itself to false. I think I'm setting the core/global as well with no help but I need to spend some time on it to verify. In OP2Utility, entire files are listed as changed for just changing 3 lines since every line ending is getting updated.

The nice part about littering everyone's local repository with a settings file is they know what the repository expects by examining it, possibly before jumping in and commiting code with different line endings than the owner wants.

Not really sure what I want here, except that I don't want to be worried about line endings on top of all the other concerns attached to coding. I just want it to work and not muddy up changes. I'll try to stop grumping about it though. Clearly setting Git to Auto for line endings isn't working anymore.

[DanRStevens]

Ahh yes, I think that's what got me originally to turn off the autocrlf setting. I was trying to checkout a Windows project on Linux, and every file appeared modified in git status. I believe git status detects file changes by comparing the file hash, hence if the line endings change, the hash changes, and the files appear modified. To make it even more frustrating, git diff showed nothing, as simple whitespace changes like that were hidden.

It seemed like the auto settings would always produce a problem for someone. Either Windows developers would see a ton of ghost changes, or Linux developers would see a ton of ghost changes. I think the setting of input was a little better, but still made magical changes. As it was my first time using Git, I wasn't exactly pleased I had to spend time researching this issue right off the bat.

At any rate, my personal preference to for the version control system to get out of the way, and not make any magical changes to the files. Besides, there is no way it can get it right 100% of the time. It can't know if a file is text or binary, with certainty, without being told, and changing a binary file would corrupt it. At best, it can use heuristics to get it right most of the time. Seems like a broken solution to the wrong problem to me. The real problem is text editors and tools that can only handle one of the platform specific LF or CRLF.

The .gitattributes file does nothing to enforce repository policy. Hence using one is also not a solution in that regards. It merely sets default settings, which most programmers won't even be aware of. When they are set badly, I've found myself making temporary changes to .gitattributes while I work, effectively disabling the settings, and then just not committing my local changes to that file. Related, most people don't really know what the settings in that file do, or how they work, and the settings are named in a not very descriptive and possibly misleading way, so I wouldn't count on them being correct.

There's a bit of info on the options over at Git Configuration.

In terms of policy enforcement, I think that's what Git Hooks are able to do, as they can actually stop a commit if it fails a certain check script.

---

Ranting aside, sorry to hear you're having trouble with this. Does it appear to be doing EOL conversions even though the setting is false? Does this affect Git status, Git diff, or both? Does it differ between Git clients? I believe use of the .gitattributes file is dependent on the Git client you use. In particular, I think I once read a bug report suggesting Visual Studio's Git plugin didn't respect the autocrlf setting in a .gitattributes file.