Hi,

Am Freitag, den 04.05.2018, 07:43 -0700 schrieb Elijah Newren:

On Fri, May 4, 2018 at 3:18 AM, Heiko Voigt [off-list ref] wrote:

quoted

Hi,

On Fri, May 04, 2018 at 08:29:32AM +0000, Middelschulte, Leif wrote:

quoted

Am Donnerstag, den 03.05.2018, 18:42 +0200 schrieb Heiko Voigt:

<snip>

quoted

quoted

quoted

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...

quoted

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