Hi, firstofall: thank all of you for your feedback. Am Donnerstag, den 26.04.2018, 17:19 -0700 schrieb Elijah Newren: > On Thu, Apr 26, 2018 at 3:49 AM, Middelschulte, Leif > <Leif.Middelschulte@xxxxxxxxxxxxx> 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? Shouldn't git be like: "hey, you're trying to merge two different contents for the same line" (the submodule's revision) > > Hard to say without saying what commit was referenced for the > submodule in the merge-bases for the two repositories you have. In > the basic case.. > > If branch A and branch B have different commits checked out in the > submodule, say: > A: deadbeef > B: ba5eba11 > > then it's not clear whether there's a conflict or not. The merge-base > (the common point of history) matters. So, for example if the > original version (which I'll refer to as 'O") had: > O: deadbeef > > then you would say, "Oh, branch A made no change to this submodule but > B did. So let's go with what B has." Conversely, of O had ba5eba11, > then you'd go the other way. > > But, there is some further smarts in that if either A or B point at > commits that contain the other in their history and both contain the > commit that O points at, then you can just do a fast-forward update to > the newest. > > > You didn't tell us how the merge-base (cd5e1a5 from the diagram you > gave) differed in your example here between the two repositories. In > fact, the non-linear case could have several merge-bases, in which > case they all become potentially relevant (as does their merge-bases > since at that point you'll trigger the recursive portion of > merge-recursive). Giving us that info might help us point out what > happened, though if either the fast-forward logic comes into play or > the recursive logic gets in the mix, then we may need you to provide a > testcase (or access to the repo in question) in order to explain it > and/or determine if you've found a bug. I placed two reositories here: https://gitlab.com/foss-contributions/git-examples/network/develop The access should be public w/o login. If you prefer the examples to be placed somewhere else, let me know. > > Does that help? I guess it's somehow understandable that it tries to be more smart about things wrt submodules. However, I believe that there should be some kind of choice here. Not giving *any* notice, makes testing feature-branches hell. I hope the provided example exhibits the challenge. BR, Leif > > Elijah >
