From: Dan Loewenherz <hidden> Date: 2016-06-15 22:49:23
Hi all,
I may be mistaking a design decision as a bug, but I wanted to throw
this out to the list to make sure. I think that re-enacting it will be
the best way to explain it.
$ mkdir test
$ cd test
$ git init
$ cat > readme
This is a test file.
^D
$ git commit -am "first commit"
[master (root-commit) fae0d05] first commit
1 files changed, 1 insertions(+), 0 deletions(-)
For personal reasons, I now want readme to be uppercase.
$ mv readme README
$ cat > README
This is the revised README.
$ git status -sb
## master
M readme
$ git add README
$ git status -sb
## master
M readme
At this point, I'm thinking that git is confused. Even though I've
added the README file, it still isn't staged. I follow up with the
obvious:
$ git add readme
$ git status -sb
## master
M readme
$ git commit -m "change filename"
[master ecc009f] change filename
1 files changed, 1 insertions(+), 1 deletions(-)
It kind of works, but not quite, since git still thinks the file is
called readme. I'd like to rename it, but whenever I run:
$ git mv readme README
fatal: destination exists, source=readme, destination=README
How about this:
$ mv README README.temp
$ git mv readme README
fatal: bad source, source=readme, destination=README
The only workable solution was this:
$ git mv readme readme.temp
$ git mv readme.temp README
I'm guessing this all has to do in some part with the logic behind
git's strategy for detecting renames. This case probably slipped under
the radar.
-Dan
I may be mistaking a design decision as a bug, but I wanted to throw
this out to the list to make sure. I think that re-enacting it will be
the best way to explain it.
$ mkdir test
$ cd test
$ git init
$ cat > readme
This is a test file.
^D
$ git commit -am "first commit"
[master (root-commit) fae0d05] first commit
1 files changed, 1 insertions(+), 0 deletions(-)
For personal reasons, I now want readme to be uppercase.
$ mv readme README
$ cat > README
This is the revised README.
$ git status -sb
## master
M readme
[...]
Thanks for taking the time to explain! Unfortunately, I'm not able to
reproduce this. Which version of Git are you using, and which platform
are you on?
-- Ram
From: Michael J Gruber <hidden> Date: 2016-06-15 22:49:23
Dan Loewenherz venit, vidit, dixit 27.08.2010 06:57:
Hi all,
I may be mistaking a design decision as a bug, but I wanted to throw
this out to the list to make sure. I think that re-enacting it will be
the best way to explain it.
$ mkdir test
$ cd test
$ git init
$ cat > readme
This is a test file.
^D
$ git commit -am "first commit"
[master (root-commit) fae0d05] first commit
1 files changed, 1 insertions(+), 0 deletions(-)
? You have not added any file, so git won't commit anything (not even
with -a). The above can't be a complete transcription. I assume you've
added readme with the content above.
For personal reasons, I now want readme to be uppercase.
$ mv readme README
Here's where using "git mv" would have been the easier choice, followed
by commit.
$ cat > README
This is the revised README.
Renaming and changing the content completely in one step will always
trip up git's rename detection. You should rename, commit, change,
commit, unless the change affects a small portion of the file only.
$ git status -sb
## master
M readme
Again, this can't be a complete transcript. The above would lead to
D readme
?? README
$ git add README
$ git status -sb
## master
M readme
At this point, I'm thinking that git is confused. Even though I've
Are you possibly using a case-challenged file system? Is this maybe on a
Mac with HFS or Win with NTFS?
Michael
From: Dan Loewenherz <hidden> Date: 2016-06-15 22:49:23
On Fri, Aug 27, 2010 at 1:00 AM, Michael J Gruber
[off-list ref] wrote:
Dan Loewenherz venit, vidit, dixit 27.08.2010 06:57:
quoted
Hi all,
I may be mistaking a design decision as a bug, but I wanted to throw
this out to the list to make sure. I think that re-enacting it will be
the best way to explain it.
$ mkdir test
$ cd test
$ git init
$ cat > readme
This is a test file.
^D
$ git commit -am "first commit"
[master (root-commit) fae0d05] first commit
1 files changed, 1 insertions(+), 0 deletions(-)
? You have not added any file, so git won't commit anything (not even
with -a). The above can't be a complete transcription. I assume you've
added readme with the content above.
Yep, that was my mistake. I left out 'git add readme'.
quoted
For personal reasons, I now want readme to be uppercase.
$ mv readme README
Here's where using "git mv" would have been the easier choice, followed
by commit.
I agree. The instance where this actually occurred was that I had
received an updated binary file to put into my repository. icon.png ->
Icon.png. I suppose I could've run 'git mv' but I didn't realize what
would happen if I didn't!
quoted
$ cat > README
This is the revised README.
Renaming and changing the content completely in one step will always
trip up git's rename detection. You should rename, commit, change,
commit, unless the change affects a small portion of the file only.
Agreed.
quoted
$ git status -sb
## master
M readme
Again, this can't be a complete transcript. The above would lead to
D readme
?? README
This is where I didn't botch up the transcript, and where I was
actually surprised at what was going on. I'll insert a full one at the
bottom of this email that can actually be run to get the same results.
quoted
$ git add README
$ git status -sb
## master
M readme
At this point, I'm thinking that git is confused. Even though I've
Are you possibly using a case-challenged file system? Is this maybe on a
Mac with HFS or Win with NTFS?
I'm using a Mac with a journaled filesystem and Git version 1.7.2.1.
Michael
Transcript
dan ~ $ mkdir test
dan ~ $ cd test/
dan test $ git init
Initialized empty Git repository in /Users/dan/test/.git/
dan test (master #) $ cat > readme
This is a test file.
dan test (master #%) $ git add readme
dan test (master #) $ git ci -m "first commit"
[master (root-commit) 3237fcb] first commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 readme
dan test (master) $ mv readme README
dan test (master) $ cat > README
This is the revised README.
dan test (master *) $ git s
## master
M readme
dan test (master *) $ git add README
dan test (master *) $ git s
## master
M readme
dan test (master *) $ git add readme
dan test (master +) $ git s
## master
M readme
dan test (master +) $ git ci -m "change filename"
[master 587f3f8] change filename
1 files changed, 1 insertions(+), 1 deletions(-)
dan test (master) $ git --version
git version 1.7.2.1
From: Michael J Gruber <hidden> Date: 2016-06-15 22:49:23
Dan Loewenherz venit, vidit, dixit 27.08.2010 16:52:
On Fri, Aug 27, 2010 at 1:00 AM, Michael J Gruber
[off-list ref] wrote:
quoted
Dan Loewenherz venit, vidit, dixit 27.08.2010 06:57:
quoted
Hi all,
I may be mistaking a design decision as a bug, but I wanted to throw
this out to the list to make sure. I think that re-enacting it will be
the best way to explain it.
$ mkdir test
$ cd test
$ git init
$ cat > readme
This is a test file.
^D
$ git commit -am "first commit"
[master (root-commit) fae0d05] first commit
1 files changed, 1 insertions(+), 0 deletions(-)
? You have not added any file, so git won't commit anything (not even
with -a). The above can't be a complete transcription. I assume you've
added readme with the content above.
Yep, that was my mistake. I left out 'git add readme'.
quoted
quoted
For personal reasons, I now want readme to be uppercase.
$ mv readme README
Here's where using "git mv" would have been the easier choice, followed
by commit.
I agree. The instance where this actually occurred was that I had
received an updated binary file to put into my repository. icon.png ->
Icon.png. I suppose I could've run 'git mv' but I didn't realize what
would happen if I didn't!
quoted
quoted
$ cat > README
This is the revised README.
Renaming and changing the content completely in one step will always
trip up git's rename detection. You should rename, commit, change,
commit, unless the change affects a small portion of the file only.
Agreed.
quoted
quoted
$ git status -sb
## master
M readme
Again, this can't be a complete transcript. The above would lead to
D readme
?? README
This is where I didn't botch up the transcript, and where I was
actually surprised at what was going on. I'll insert a full one at the
bottom of this email that can actually be run to get the same results.
quoted
quoted
$ git add README
$ git status -sb
## master
M readme
At this point, I'm thinking that git is confused. Even though I've
Are you possibly using a case-challenged file system? Is this maybe on a
Mac with HFS or Win with NTFS?
I'm using a Mac with a journaled filesystem and Git version 1.7.2.1.
The journalling is no problem, but HFS is. I'm no Macxpert but if I
remember correctly, then under HFS "readme" and "README" are the same
file, i.e. HFS only remembers how you want it spelled. People will
correct me where I'm wrong.
Your test script should produce the expected result if you use, say,
"readme" and "RAEDME" , i.e. names which differ by more than just case.
Cheers,
Michael
From: Stephen Bash <hidden> Date: 2016-06-15 22:49:23
quoted
I'm using a Mac with a journaled filesystem and Git version 1.7.2.1.
The journalling is no problem, but HFS is. I'm no Macxpert but if I
remember correctly, then under HFS "readme" and "README" are the same
file, i.e. HFS only remembers how you want it spelled. People will
correct me where I'm wrong.
Your test script should produce the expected result if you use, say,
"readme" and "RAEDME" , i.e. names which differ by more than just
case.
It's a problem on some (most?) Macs. A while back Apple introduced an option to format a partition as case sensitive (Wikipedia implies 10.3 introduced this feature). For a long time after the feature was introduced the factory install continued to be not case sensitive, but I don't know if that's still the case (no pun intended).
Stephen
From: Jay Soffian <hidden> Date: 2016-06-15 22:49:23
On Fri, Aug 27, 2010 at 11:46 AM, Michael J Gruber
[off-list ref] wrote:
The journalling is no problem, but HFS is. I'm no Macxpert but if I
remember correctly, then under HFS "readme" and "README" are the same
file, i.e. HFS only remembers how you want it spelled. People will
correct me where I'm wrong.
That's correct, HFS is case-preserving but case-insensitve. There is a
case-sensitive variant but it is not the default and sadly, some
applications assume case-insensitity and will break if the system
volume is otherwise.
j.
On Fri, Aug 27, 2010 at 15:46, Michael J Gruber
[off-list ref] wrote:
The journalling is no problem, but HFS is. I'm no Macxpert but if I
remember correctly, then under HFS "readme" and "README" are the same
file, i.e. HFS only remembers how you want it spelled. People will
correct me where I'm wrong.
FWIW this is called "case preserving". Where the filesystem is
case-insensitive so that you can't create both "foo" and "FOO", but it
still remembers if you did "touch Foo", "touch FoO" or whatever.
It affects more filesystems than just HFS.