From: "Middelschulte, Leif" <Leif.Middelschulte@klsmartin.com>
To: "newren@gmail.com" <newren@gmail.com>,
"hvoigt@hvoigt.net" <hvoigt@hvoigt.net>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
"sbeller@google.com" <sbeller@google.com>,
"jacob.keller@gmail.com" <jacob.keller@gmail.com>
Subject: Re: git merge banch w/ different submodule revision
Date: Mon, 7 May 2018 14:23:16 +0000 [thread overview]
Message-ID: <1525702992.2177.3.camel@klsmartin.com> (raw)
In-Reply-To: <CABPp-BGaibCPWuCnaX5Af=sv-2zvyhNcupT+-PkxHDfJBg_Vbw@mail.gmail.com>
Hi,
Am Freitag, den 04.05.2018, 07:43 -0700 schrieb Elijah Newren:
> 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
next prev parent reply other threads:[~2018-05-07 14:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-26 10:49 git merge banch w/ different submodule revision Middelschulte, Leif
2018-04-26 17:56 ` Stefan Beller
2018-04-26 21:46 ` Jacob Keller
2018-04-26 22:19 ` Stefan Beller
2018-04-30 17:02 ` Heiko Voigt
2018-05-02 7:30 ` Middelschulte, Leif
2018-05-03 16:42 ` Heiko Voigt
2018-05-04 8:29 ` Middelschulte, Leif
2018-05-04 10:18 ` Heiko Voigt
2018-05-04 14:43 ` Elijah Newren
2018-05-07 14:23 ` Middelschulte, Leif [this message]
2018-04-27 0:02 ` Elijah Newren
2018-04-27 0:19 ` Elijah Newren
2018-04-27 10:37 ` Middelschulte, Leif
2018-04-28 0:24 ` Elijah Newren
2018-04-28 7:22 ` Jacob Keller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1525702992.2177.3.camel@klsmartin.com \
--to=leif.middelschulte@klsmartin.com \
--cc=git@vger.kernel.org \
--cc=hvoigt@hvoigt.net \
--cc=jacob.keller@gmail.com \
--cc=newren@gmail.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).