From: Robert Dailey <email@example.com> To: Git <firstname.lastname@example.org> Subject: Re: Rename of file is causing changes to be lost Date: Tue, 13 Mar 2018 09:32:06 -0500 Message-ID: <CAHd499CKneW5FoeOCgfv4uzvuOVsV-c5FKH_MgDDEgSsJJ7PTg@mail.gmail.com> (raw) In-Reply-To: <CAHd499Axo7HFviUJavigTZ6BGZCkj9iOSeNVndu1oPivkPv+5Q@mail.gmail.com> On Thu, Mar 8, 2018 at 10:01 AM, Robert Dailey <email@example.com> wrote: > 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): > > #/bin/bash > 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? I wanted to bump this and see if anyone would have a spare few minutes to help me out with this. I know it's a needlessly complex situation, but I'd really love to know how to resolve the specific issue, or perhaps learn a better way to approach this in the future if I'm shooting myself in the foot here. Thanks again.
next prev parent reply index Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-08 16:01 Robert Dailey 2018-03-13 14:32 ` Robert Dailey [this message] 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAHd499CKneW5FoeOCgfv4uzvuOVsV-c5FKH_MgDDEgSsJJ7PTg@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ /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
firstname.lastname@example.org list mirror (unofficial, one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git 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: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox