On Tue, Sep 6, 2016 at 3:00 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins <dakotahawkins@xxxxxxxxx> wrote: >> Below is a simple reproduction of the issue. >> >> The _real_ problem is that this is how our pull request merges work, > > So your workflow is the problem or is the actual bug just exposed in > your workflow? I believe the workflow just exposes the problem, which is that generically for this case a fast-forward merge works without conflicts while a non-fast-forward merge fails with conflicts. Sorry if this confuses the issue, it's just how we experienced it so I wanted to add that background. >> ## Test fast-forward merge, this will work >> git checkout -b merge-ff-test master # warning: unable to rmdir >> submodule-location-2: Directory not empty >> rm -rf ./submodule-location-2 >> git merge --ff-only move-submodule >> > > And no reset/rm in between, i.e. we still have > submodule-location-2 from merge-ff-test still around? That is true in that example, but somewhat immaterial. The first merge was only to demonstrate that a fast-forward merge works without conflict. The simplest reproduction is to skip that and get straight to the failure case: ## Clone and setup branches git clone https://github.com/dakotahawkins/submodule-move-merge-bug-main-repo.git cd submodule-move-merge-bug-main-repo git branch move-submodule origin/move-submodule git checkout -b merge-no-ff-test master ## This will fail git merge --no-ff move-submodule # Auto-merging submodule-location-2 # Adding as submodule-location-2~move-submodule instead # Automatic merge failed; fix conflicts and then commit the result. Does that make things a little bit clearer? Dakota