On Thu, Apr 26, 2018 at 3:49 AM, Middelschulte, Leif <leif.middelschu...@klsmartin.com> wrote: > Hi, > > we're using git-flow as a basic development workflow. However, doing so > revealed unexpected merge-behavior by git. > > Assume the following setup: > > - Repository `S` is sourced by repository `p` as submodule `s` > - Repository `p` has two branches: `feature_x` and `develop` > - The revisions sourced via the submodule have a linear history > > > * 1c1d38f (feature_x) update submodule revision to b17e9d9 > | * 3290e69 (HEAD -> develop) update submodule revision to 0598394 > |/ > * cd5e1a5 initial submodule revision > > > Problem case: Merge either branch into the other > > Expected behavior: Merge conflict. > > Actual behavior: Auto merge without conflicts. > > Note 1: A merge conflict does occur, if the sourced revisions do *not* have a > linear history > > Did I get something wrong about how git resolves merges?
We often treating a submodule as a file from the superproject, but not always. And in case of a merge, git seems to be a bit smarter than treating it as a textfile with two different lines. See https://github.com/git/git/commit/68d03e4a6e448aa557f52adef92595ac4d6cd4bd (68d03e4a6e (Implement automatic fast-forward merge for submodules, 2010-07-07) to explain the situation you encounter. (specifically merge_submodule at the end of the diff) > Shouldn't git be like: "hey, you're trying to merge two different contents > for the same line" (the submodule's revision) As we have a history in the submodule we can do more than that and resolve the conflict. For two lines, you usually need manual intervention (which line to pick, or craft a complete new line out of parts of each line?), whereas for submodule commits you can reason about their dependencies due to their history and not just look at the textual conflict. Stefan
