Hi, Am Donnerstag, den 03.05.2018, 18:42 +0200 schrieb Heiko Voigt: > 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? In that case you'd be right. I should have picked my example more wisely. Assume right here that not a core developer, but another developer advanced the submodule (also via feature branch + merge). > > It seems to me that you do not want to mix integration testing and > testing of the feature itself. That's on point. That's why it would be nice if git *at least* warned about the different revisions wrt submodules. But, I guess, I learned something about submodules: I used to think of submodules as means to pin down a specific revision like: `ver == x`. Now I'm learning that submodules are treated as `ver >= x` during a merge. > 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. Sure. But if the behavior deviates after a merge the merging developer is currently not aware that it *might* have to do with different submodule revisions used, not the "actual" code merged. Like not even "beware: the (feature) branch you've merged used an 'older' revision of X" > > Cheers Heiko Cheers, Leif
