On Tue, Sep 6, 2016 at 3:00 PM, Stefan Beller <sbel...@google.com> wrote:
> On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins <dakotahawk...@gmail.com>
>> 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
>> ## 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 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?