git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Robert Dailey <rcdailey.lists@gmail.com>
Cc: Git <git@vger.kernel.org>
Subject: Re: Rename of file is causing changes to be lost
Date: Tue, 13 Mar 2018 09:51:05 -0700
Message-ID: <CABPp-BEC48EoTc5eyLrcaLLtUexgbShQsB7zbQJB0QE6AA19kA@mail.gmail.com> (raw)
In-Reply-To: <CAHd499Axo7HFviUJavigTZ6BGZCkj9iOSeNVndu1oPivkPv+5Q@mail.gmail.com>

On Thu, Mar 8, 2018 at 8:01 AM, Robert Dailey <rcdailey.lists@gmail.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?

Cool, thanks for the testcase.  I don't have a good workaround for
you, but this is clearly a bug in the merge-recursive logic in git.  I
guess it's what might be called a rename/add/delete conflict, which
git just doesn't handle.  Your testcase triggers the bug just fine on
linux, though you can trigger the exact same bug without case
sensitivity using a slightly different setup (and no need for an
interactive rebase):

------
git init foobar
cd foobar
echo "original file" >foo
git add foo
git commit -m "original"
git branch L
git branch R

git checkout L
git rm foo
echo "different file" >bar
git add bar
git commit -m "Remove foo, add bar"

git checkout R
git mv foo bar
git commit -m "rename foo to bar"

git merge L
-------

git has code to handle rename/delete conflicts and rename/add
conflicts, but since one side of history BOTH deleted foo and added an
unrelated bar, that means both types of changes are relevant to the
same path (bar) -- essentially, a rename/delete/add conflict.  Sadly,
git only goes down a codepath that handles one of those two (the
rename/delete), and incorrectly throws away the separate add:

-----
$ git ls-files -s
100644 78fa0f415ae2bdb5c0182c067eacaaf843699b39 2    bar

$ git ls-tree -r master
100644 blob 78fa0f415ae2bdb5c0182c067eacaaf843699b39    foo
$ git ls-tree -r L
100644 blob f286e5cdd97ac6895438ea4548638bb98ac9bd6b    bar
$ git ls-tree -r R
100644 blob 78fa0f415ae2bdb5c0182c067eacaaf843699b39    bar
-----

But the problem is actually a bit bigger than shown here; there are
higher order corner cases here too.  I realized in the past that e.g.
rename/rename(1to2) could also have rename/add conflicts for each
rename (thus making a rename/rename/add/add conflict possible), but I
also felt there were probably some other bad interactions out there.
I figured they were likely theoretical only, so I didn't bother
investigating.  But, combining your example with that other one, we
should also be able to come up with a
rename/rename/add/add/delete/delete conflict.  I wonder if there are
others...

Anyway, I recorded this at
https://bugs.chromium.org/p/git/issues/detail?id=11.  Sorry I don't
have a workaround, but I'll try to eventually get back to this and fix
it.

  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
2018-03-13 16:51 ` Elijah Newren [this message]
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=CABPp-BEC48EoTc5eyLrcaLLtUexgbShQsB7zbQJB0QE6AA19kA@mail.gmail.com \
    --to=newren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=rcdailey.lists@gmail.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

git@vger.kernel.org mailing list mirror (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/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox