From: Dan Loewenherz <dloewenherz@gmail.com>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: git@vger.kernel.org
Subject: Re: Does changing filename case breaks git's rename heuristic?
Date: Fri, 27 Aug 2010 07:52:11 -0700 [thread overview]
Message-ID: <AANLkTikN_PbNNH2f4zWuk1FH+LgpKzkoZ6mYOdT9ANBj@mail.gmail.com> (raw)
In-Reply-To: <4C777090.2000107@drmicha.warpmail.net>
On Fri, Aug 27, 2010 at 1:00 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> 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.
Yep, that was my mistake. I left out 'git add readme'.
>
>>
>> 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!
>
>> $ 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.
>
>> $ 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.
>
>> $ 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
next prev parent reply other threads:[~2010-08-27 14:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-27 4:57 Does changing filename case breaks git's rename heuristic? Dan Loewenherz
2010-08-27 5:36 ` Ramkumar Ramachandra
2010-08-27 8:00 ` Michael J Gruber
2010-08-27 14:52 ` Dan Loewenherz [this message]
2010-08-27 15:46 ` Michael J Gruber
2010-08-27 16:22 ` Stephen Bash
2010-08-27 20:02 ` Jay Soffian
2010-08-28 10:39 ` Ævar Arnfjörð Bjarmason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTikN_PbNNH2f4zWuk1FH+LgpKzkoZ6mYOdT9ANBj@mail.gmail.com \
--to=dloewenherz@gmail.com \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).