Question

I have a small scripting project that consists of five different source files in one directory called “Droid XX-XX-XX”. Each time I created a new backup copy of the source directory, I put the date in the X’s. So there are about 15 different versions from different dates. I want to add each of these to my bare new Git repository starting from the earliest.

However I have run into several problems.

1. One problem is that some of the files use tabs for indentation, while others use spaces — but Git treats a whole line as different even when the only difference is the tab vs. space issue. How can I make Git ignore indentation formatting?

2. Another problem is that some filenames would have no spaces while others had spaces between the words — but Git treats them as different files. Worse, sometimes the filename was changed to something different (like “PatrolPlan” changed to just “Patrol”) for no real reason. When I’m adding a new set of files, how can I tell Git that even though the filename is different, it’s really just a new version of a certain older file? Or better yet, can I set it to auto-detect when this happens?

3. The last problem is that at certain points during development, we merged two source files into one, or split one into two — but Git doesn’t automatically detect the similarities and deduce what happened. How can I tell Git what happened? Or better yet, how can I set it to auto-detect when two source files were combined or when one was split up?

I realize questions (2) and (3) are highly related. Thanks for any assistance!

Answer 1

It’s sounding like you need more control and standardization of the development process. The one who commits changes should be the same person who modifies the files. Or at least the committer should know exactly what changed.

Examine carefully the output of git diff, and use the -w flag to ignore spaces. There’s also options to show differences within a line. See Diffs within a line below.

Note that you won’t be able to tell git to skip the space changes when committing. I suggest using GitX (I prefer the “brotherbard” fork), which allows you to interactively discard hunks before committing.

Use descriptive messages when committing. For example, if a file was split, say so. Make your commits small. If you find yourself writing long commit messages, break up the commit into smaller parts. That way when you examine the logs a long time later, it will make more sense what changed.

Diffs within a line

Git has some ability to show “word” differences in a single line. The simplest way is to just use git diff --color-words.

However, I like customizing the meaning of a “word” using the diff.wordRegex config. I also like the plain word-diff format because it more clearly shows where the differences are (inserts brackets around the changes in addition to using color).

Command:

git diff --word-diff=plain

along with this in my config:

[diff]
        wordRegex = [[:alnum:]_]+|[^[:alnum:]_[:space:]]+

This regex treats these as “words”:

• consecutive strings of alphanumerics and underscores
• consecutive strings of non-alphanumerics, non-underscores, and non-spaces (good for detecting operators)

You must have a recent version of git to use wordRegex. See your git-config man page to see if the option is listed.

UPDATE

If you use git mv to rename a file (which is preferable to using another tool or the OS to rename), you can see git detecting the rename. I highly recommend committing a rename independently of any edits to the contents of the file. That’s because git doesn’t actually store the fact that you renamed – it uses a heuristic based on how much the file has changed to guess whether it was the same file. The less you change it during the rename-commit, the better.

If you did change the file contents slightly, you can use -C param to git diff and git log to try harder to detect copies and renames. Add a percentage (e.g. -C75%) to make git more lenient about differences. The percent represents how similar the contents have to be to be considered a match.