Any ideas on this anywhere?

In my opinion if a merge can fast-forward without conflict it should
trivially be able to non-fast-forward without conflict.

Also, I'm not too familiar/comfortable with mailing list etiquette,
and I don't want to be a bother by continuing to ping this thread.



On Tue, Sep 6, 2016 at 4:02 PM, Dakota Hawkins <> wrote:
> On Tue, Sep 6, 2016 at 3:00 PM, Stefan Beller <> wrote:
>> On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins <> 
>> 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 
> 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

Reply via email to