Git Scenarios is a recurring LabKitty feature wherein we examine weird / badly-documented git behaviors that may vex the git n00b (and the not-so n00b).
The OS-X filesystem is not case sensitive. That means, for example, it cannot tell the difference between a file named foobar.txt and FOOBAR.txt. You can easily verify this. Open Terminal and do:
The first ls will list the file and the second will not.
Unfortunately, this can create git weirdness. Read on.
For example, suppose you wish to rename a file in a repository to use only lowercase characters. Assume FOOBAR.txt is the offending file. You do the entirely reasonable:
However, git will not recognize that anything has changed. You cannot add, you cannot commit. Git status says up-to-date.
Git does not recognize the file has changed because OS-X does not recognize the file has changed.
To get this done, you must: 1) delete FOOBAR, 2) add and commit, 3) create a new file foobar with the contents of FOOBAR, 4) add & commit.
That doesn't sound too terrible, but potential confusion arises if both the file name and the file contents change. For example, if FOOBAR.m is a Matlab function, you know the function name must match the filename. So, again considering the previous scenario, we now change the filename *and* edit the function name inside the file -- that is, after renaming the file we change the first line of the file
to
to make Matlab happy.
Now a git status will tell you the file has been changed but that's only because the contents have changed. Git is ignoring the file name change. If you add & commit (and perhaps then push & open a PR), git will still be using the old filename.
Git apologists blame OS-X for this. Dear Git apologists: OS-X was here first. If your fancy pants SVC tool can't properly deal with filenames on a given platform, then don't support the platform.
Or, you know, at least warn users of the potential problem somewhere in the documentation.
Git delenda est.
The OS-X filesystem is not case sensitive. That means, for example, it cannot tell the difference between a file named foobar.txt and FOOBAR.txt. You can easily verify this. Open Terminal and do:
$ touch foobar
$ ls foobar
$ rm FOOBAR
$ ls foobar
$ ls foobar
$ rm FOOBAR
$ ls foobar
The first ls will list the file and the second will not.
Unfortunately, this can create git weirdness. Read on.
For example, suppose you wish to rename a file in a repository to use only lowercase characters. Assume FOOBAR.txt is the offending file. You do the entirely reasonable:
$ mv FOOBAR foobar
However, git will not recognize that anything has changed. You cannot add, you cannot commit. Git status says up-to-date.
Git does not recognize the file has changed because OS-X does not recognize the file has changed.
To get this done, you must: 1) delete FOOBAR, 2) add and commit, 3) create a new file foobar with the contents of FOOBAR, 4) add & commit.
That doesn't sound too terrible, but potential confusion arises if both the file name and the file contents change. For example, if FOOBAR.m is a Matlab function, you know the function name must match the filename. So, again considering the previous scenario, we now change the filename *and* edit the function name inside the file -- that is, after renaming the file we change the first line of the file
function FOOBAR()
to
function foobar()
to make Matlab happy.
Now a git status will tell you the file has been changed but that's only because the contents have changed. Git is ignoring the file name change. If you add & commit (and perhaps then push & open a PR), git will still be using the old filename.
Git apologists blame OS-X for this. Dear Git apologists: OS-X was here first. If your fancy pants SVC tool can't properly deal with filenames on a given platform, then don't support the platform.
Or, you know, at least warn users of the potential problem somewhere in the documentation.
Git delenda est.
No comments:
Post a Comment