Show 38 quoted lines
> On Fri, May 4, 2018 at 3:18 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> > Hi,
> >
> > On Fri, May 04, 2018 at 08:29:32AM +0000, Middelschulte, Leif wrote:
> > > Am Donnerstag, den 03.05.2018, 18:42 +0200 schrieb Heiko Voigt:
>
> <snip>
> > > > 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.
>
> There's a good point here...
>
> > Well a submodule version is pinned down as long a you do not change it
> > and commit it. The same as files and the goal is to make submodules
> > behave as close to normal files as possible. And git "warns" about
> > changed submodules by displaying them in the diff.
>
> Actually, submodules do behave differently than normal files in an
> important way, which we may be able to fix and may help Leif here:
>
> When merging two regular files that have been modified on both sides
> of history, git always prints a message, "Auto-merging $FILE". We
> could omit that and depend on the user to check the diffstat or run
> diff afterwards or something, but we don't just rely on that; we also
> warn them with a simple message that we are doing something to resolve
> this both-sides-changed-this-path (namely employing the well known
> three-way-file-merge algorithm to come up with something).
>
> Inside merge_submodule(), the equivalent would be printing a message
> whenever we decide that one branch is a fast-forward of the other
> ("Case #1", as it's called in the code), yet currently it prints
> nothing. Perhaps it should.
>
>
> Leif, would you like to try your hand at creating a patch for this?Thanks for the feedback and the advice/direction.
I'll try to work on it this week and send patches to the ML for review.
Cheers,
Leif