# git merge bug: creating new files in one branch in a directory that is renamed in another 3 messages from 2007-01-21 to 2007-01-21. Participants: Liraz Siri, Shawn O. Pearce, Johannes Schindelin. Thread: https://gitlist.dev/t/6460 ## Liraz Siri, 2007-01-21 08:20 Subject: git merge bug: creating new files in one branch in a directory that is renamed in another Message-ID: <45B3224B.3020800@gmail.com> URL: https://gitlist.dev/e/45B3224B.3020800%40gmail.com ``` Hey all, I'm running a few tests to figure out when git does the right thing on merges, and I've discovered that git does not do the right thing if you are creating new files in one branch in a directory that is renamed in another. Merging edits of files in dir/ in one branch and renaming dir/ to newdir/ in another branch works, but if you create files in the renamed dir/ then after the merge they will still remain in dir/, rather than newdir/. Here is some example output from a test merge: $ git-merge XXX HEAD fork Trying really trivial in-index merge... fatal: Merge requires file-level merging Nope. Merging HEAD with 68aaa44a864cde7a1b83a65a8d5c70cc6c42ac7b Merging: 85ba656 liraz renamed t to t2 68aaa44 created t/newfile found 1 common ancestor(s): 9e42cd6 xxx Merge made by recursive. t/newfile | 1 + t2/liraz1 | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 t/newfile Cheers, Liraz ``` ## Shawn O. Pearce, 2007-01-21 08:44 Subject: Re: git merge bug: creating new files in one branch in a directory that is renamed in another Message-ID: <20070121084405.GB10632@spearce.org> URL: https://gitlist.dev/e/20070121084405.GB10632%40spearce.org In-Reply-To: <45B3224B.3020800@gmail.com> ``` Liraz Siri wrote: > I'm running a few tests to figure out when git does the right thing on > merges, and I've discovered that git does not do the right thing if you > are creating new files in one branch in a directory that is renamed in > another. Well, it depends on your definition of "the right thing" as to whether or not Git does it. :-) > Merging edits of files in dir/ in one branch and renaming dir/ to > newdir/ in another branch works, but if you create files in the renamed > dir/ then after the merge they will still remain in dir/, rather than > newdir/. Yes. We don't actually track directories, we track contents of files. Renaming a directory in one branch and adding a file to that directory in the other branch does not imply that after the merge the new file belongs in the renamed location. Nor does it imply it should be in the old location, but that is where we currently put it. We probably could modify merge-recursive to rename new files added by the second branch if: - the file from the second branch does not exist in the merge base (hence it was added by the second branch); - the file from the second branch is located under a path where a prefix of directories exists within the merge base; - all files in the merge base under that path prefix were either deleted or renamed to the another path prefix by the first branch. but I'm not sure how often that occurs in practice that its worth implmenting, as the implementation is slightly non-trivial. Especially since it needs to be done for both sides. -- Shawn. ``` ## Johannes Schindelin, 2007-01-21 22:05 Subject: Re: git merge bug: creating new files in one branch in a directory that is renamed in another Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0701212301340.22628%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <45B3224B.3020800@gmail.com> ``` Hi, > [merge branch where directory was renamed, but files were added in the > unrenamed directory] I think this problem is fundamentally untractable. If you move only some files to another directory, it is more obvious that you don't know where to put the newly created file (indeed, you might need it in _both_). Another non-obvious reason to fail is that you actually _want_ the new file to be the only one to reside in that directory. So I think you cannot solve that problem. IOW you have to resolve that conflict manually _anyway_. Ciao, Dscho ```