Hi, On Wed, May 02, 2018 at 07:30:25AM +0000, Middelschulte, Leif wrote: > Am Montag, den 30.04.2018, 19:02 +0200 schrieb Heiko Voigt: > > On Thu, Apr 26, 2018 at 03:19:36PM -0700, Stefan Beller wrote: > > > Stefan wrote: > > > > 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) > > > > > > +cc Heiko, author of that commit. > > > > In that commit we tried to be very careful about. I do not understand > > the situation in which the current strategy would be wrong by default. > > > > We only merge if the following applies: > > > > * The changes in the superproject on both sides point forward in the > > submodule. > > > > * One side is contained in the other. Contained from the submodule > > perspective. Sides from the superproject merge perspective. > > > > So in case of the mentioned rewind of a submodule: Only one side of the > > 3-way merge would point forward and the merge would fail. > > > > I can imagine, that in case of a temporary revert of a commit in the > > submodule that you would not want that merged into some other branch. > > But that would be the same without submodules. If you merge a temporary > > revert from another branch you will not get any conflict. > > > > So maybe someone can explain the use case in which one would get the > > results that seem wrong? > In an ideal world, where there are no regressions between revisions, a > fast-forward is appropriate. However, we might have regressions within > submodules. > > So the usecase is the following: > > Environment: > - We have a base library L that is developed by some team (Team B). > - Another team (Team A) developes a product P based on those libraries using git-flow. > > Case: > The problem occurs, when a developer (D) of Team A tries to have a feature > that he developed on a branch accepted by a core developer of P: > If a core developer of P advanced the reference of L within P (linear history), he might > deem the work D insufficient. Not because of the actual work by D, but regressions > that snuck into L. The core developer will not be informed about the missmatching > revisions of L. > > So it would be nice if there was some kind of switch or at least some trigger. I still do not understand how the current behaviour is mismatching with users expectations. Let's assume that you directly tracked the files of L in your product repository P, without any submodule boundary. How would the behavior be different? Would it be? If D started on an older revision and gets merged into a newer revision, there can always be regressions even without submodules. Why would the core developer need to be informed about mismatching revisions if he himself advanced the submodule? It seems to me that you do not want to mix integration testing and testing of the feature itself. How about just testing/reviewing on the branch then? You would still get the submodule revision D was working on and then in a later stage check if integration with everything else works. Cheers Heiko
