git merge ignores deleted files, existing on merged branch (renamed files)

I’ve got the branches feature1 and master.
Then in feature1 I renamed a file dir/file.txt into dir2/file2.txt.
After that I altered the file in master and a week later altered the file in feature1 too.

I have 40 files changed like that across the project.
When I try to merge master into feature1 I’m using low renaming threshold.
Most of the files are auto-merged correctly. Some files are offered for manual conflict resolution.

  • warning: refname 'HEAD' is ambiguous. I have No branch or tag Named “HEAD”
  • How to use git for multiple developers
  • Git: keep ignored files when switching branches
  • Good practice to use git together with svn
  • How move all commits from specific user to a new branch?
  • SSH key passphrase with git pull using Fabric
  • But some concrete files neither appear in the merge response as auto-merged,
    nor getting merged properly
    . Under properly I expect one of two outcomes I could resolve:
    1. It wouldnt detect renaming and just add me another dir/file.txt into the feature1 branch.
    2. It would detect renaming and offer me to manually resolve conflict.

    There are many changes when I view them with
    git difftool master:dir/file.txt feature1:dir2/file2.txt

    Therefore I assume that git recognizes the renaming and decides to keep my version
    without informing me about what’s going on.
    How can I solve it / debug it ?

    This is the command I use

    git config merge.renameLimit 9999999999
    git merge --no-ff -Xrename-threshold=20 -Xignore-space-change master
    

    Upd1

    While working with feature1 branch, I had deleted dir/file.txt.
    Maybe git assumes this file should be deleted and therefore ignores it’s existence in master.
    Renaming detection fails, although the similarity of the files is kept ( levenshtein distance is less than 2% of the content’s length )
    Another discussion suggests ‘manual merge’ copying files from branch to branch.

    Upd2

    Some other files are resolved correctly
    CONFLICT (rename/delete): images/ab.gif deleted in master and renamed in HEAD. Version HEAD of cdn/img/ab.gif left in tree.
    Files that were removed in master and merged into feature1 are resolved correctly. Files that are deleted (or moved) in feature1 ain’t recognized at the merge.
    Sugestions?

    Upd3

    At the moment I’m trying to merge the other way around. Merge feature1 into master and see what files
    are being added and removed. This way I’ll a list of files git fail’s to recognize as renames and resort to manual merging.

  • How to execute commands after post-receive hook
  • Files changed between commits but with limiting file list to older commit
  • git status takes too long on a shared folder on virtualbox
  • What does 'track' mean when creating a new branch in git?
  • Isolate specific folders from updating on git
  • Add another user to project owners in Github
  • 2 Solutions collect form web for “git merge ignores deleted files, existing on merged branch (renamed files)”

    If you are deleting files from your repo – git is tracking this deletion and the merge is considering this when determining what to do.

    This is probably not all that you have going on, but it is part of it. You can try git add’ing them again.

    Therefore I assume that git recognizes the renaming and decides to keep my version without informing me about what’s going on.

    Git 2.13 (Q2 2017) will actually tell you more about what is going on:

    When “git merge” detects a path that is renamed in one history while the other history deleted (or modified) it, it now reports both paths to help the user understand what is going on in the two histories being merged.

    See commit b26d87f (28 Jan 2017) by Matt McCutchen (mattmccutchen).
    (Merged by Junio C Hamano — gitster — in commit 74aabf4, 27 Feb 2017)

    merge-recursive: make “CONFLICT (rename/delete)” message show both paths

    The current message printed by “git merge-recursive” for a rename/delete
    conflict is like this:

    CONFLICT (rename/delete): 
    new-path deleted in HEAD and renamed in other-branch. 
    Version other-branch of new-path left in tree.
    

    To be more helpful, the message should show both paths of the rename and
    state that the deletion occurred at the old path, not the new path. So
    change the message to the following format:

    CONFLICT (rename/delete): 
    old-path deleted in HEAD and renamed to  new-path in other-branch.  
    Version other-branch of new-path left in tree.
    

    Since this doubles the number of cases in handle_change_delete (modify vs.
    rename), refactor the code to halve the number of cases again by merging the
    cases where o->branch1 has the change and o->branch2 has the delete with the
    cases that are the other way around.

    Git Baby is a git and github fan, let's start git clone.