mailing list mirror (one of many)
 help / Atom feed
From: Robert Dailey <>
To: Git <>
Subject: Rename of file is causing changes to be lost
Date: Thu, 8 Mar 2018 10:01:12 -0600
Message-ID: <> (raw)

I'm on Windows and core.ignorecase is set to 'true' when I clone/init
a repository. I've got a branch where I started making changes to a
file AND renamed it only to change its case. The changes I've made
were significant enough that git no longer detects a rename, instead
the files show up as "D" and "A" in git status (deleted then added).
To correct this, I do an interactive rebase to add an additional
commit before the first one to rename the file without changing it,
and *then* allow the second commit to change the file. The goal is
that rebase should detect the rename and automatically move the
changes in the (now) second commit to the newly named file. Here's a
MCVE (treat this as a script):

git init testgitrepo
cd testgitrepo/
git config core.ignorecase true # This is set by Windows for me, but
hopefully will allow this to repro on linux. Didn't test linux though.
echo "first change" > foo.txt
git add . && git commit -m 'first change'
git checkout -b topic
echo "second change" > foo.txt
git mv foo.txt FOO.txt
git add . && git commit -m 'second change'
git rebase -i master # Move line 1 to line 2, and put "x false" in line 1
git mv foo.txt FOO.txt && git commit -m 'rename foo'
git rebase --continue
git mergetool

After the rebase continue, you will get a conflict like so:

error: could not apply 527d208... second change

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Could not apply 527d208... second change
CONFLICT (rename/delete): foo.txt deleted in 527d208... second change
and renamed to FOO.txt in HEAD. Version HEAD of FOO.txt left in tree.

The last command, `git mergetool` runs, giving you the option to pick
the Created (left) or Deleted (right) version of the file:

Left: The file is created, but selecting this erases the changes from
the "added" version on the remote (which is topic). Basically the
rename of only case confused git, and we lost the changes on the
remote version of the file
Right: File is deleted. Changes are still lost.

The ideal outcome is that the changes from the "added" version of the
file in the 2nd commit get carried over to the "renamed" version of
the file, which when you compare the two are named exactly the same
after the 1st commit is introduced. How can I solve this issue?

             reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08 16:01 Robert Dailey [this message]
2018-03-13 14:32 ` Robert Dailey
2018-03-13 16:51 ` Elijah Newren
2018-03-13 18:02   ` Robert Dailey

Reply instructions:

You may reply publically 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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox