From: Jens Lehmann <Jens.Lehmann@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Nicolas Morey-Chaisemartin <devel-git@morey-chaisemartin.com>,
git@vger.kernel.org
Subject: Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict
Date: Mon, 21 Mar 2011 21:29:14 +0100 [thread overview]
Message-ID: <4D87B51A.4060609@web.de> (raw)
In-Reply-To: <7vhbb1320t.fsf@alter.siamese.dyndns.org>
Am 17.03.2011 21:50, schrieb Junio C Hamano:
> The idea is to notice the higher-stage entries, and emit only one record
> from module_list, but while doing so, mark the entry with "U" (not [0-3])
> in $stage field and null out the SHA-1 part, as the object name for the
> lowest stage does not give any useful information to the caller, and this
> way any caller that uses the object name would hopefully barf.
Excellent idea.
> Fine points:
>
> - The command called by foreach may want to do whatever it wants to do by
> noticing the merged status in the superproject itself, so I made no
> change to the function;
>
> - Init is an unlikely thing to do, but as long as a submodule is there in
> $path, there is no point skipping it. It might however want to take the
> merged status of .gitmodules into account, but that is outside of the
> scope of this topic;
Both make sense.
> - Update should refrain from touching the submodule itself. It may want
> to recurse into the submodule of the unmerged one, but people involved
> in submodule work should think things through;
I don't think recursing would make any sense here. It might be unknown
to what commit the sub-submodules should be updated to if their commits
differ in the unmerged branches. So I'd vote for not recursing at all in
this case (which is what your patch does).
> - Status does not have anything to report for an unmerged submodule. It
> may want to recurse into the submodule of the unmerged one, but people
> involved in submodule work should think things through; and
I do think status does have something to report here. First its job is to
list all submodules, so currently unmerged submodules should show up too,
and then it tells the user something about the state of the submodule. So
I would propose to print a line for the submodule starting with a special
character that tells the user the submodule has a merge conflict. We
could e.g. use a '*' here (additionally to '-' for uninitialized and '+'
for those submodules where the HEAD differs from the commit recorded in
the superproject).
> - Sync should be Ok for the same reason as Init.
Yup.
<snip>
> @@ -767,6 +789,11 @@ cmd_status()
> module_list "$@" |
> while read mode sha1 stage path
> do
> + if test "$stage" = U
> + then
> + echo >&2 "Skipping unmerged submodule $path"
As said above I would like to mimic the output for other submodule
states here. Maybe something like this (where $sha1 will expand to
the null sha as we don't have anything better here):
+ say "*$sha1 $prefix$path"
> + continue
> + fi
> name=$(module_name "$path") || exit
> url=$(git config submodule."$name".url)
> displaypath="$prefix$path"
next prev parent reply other threads:[~2011-03-21 20:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-17 8:09 [PATCH] git-submodule: Remove duplicate entries during merge with conflict Nicolas Morey-Chaisemartin
2011-03-17 18:47 ` Junio C Hamano
2011-03-17 20:50 ` Junio C Hamano
2011-03-21 8:43 ` Nicolas Morey-Chaisemartin
2011-03-21 20:53 ` Jens Lehmann
2011-03-21 20:29 ` Jens Lehmann [this message]
2011-03-21 20:59 ` Junio C Hamano
2011-03-21 21:34 ` Nicolas Morey-Chaisemartin
2011-03-21 22:01 ` Jens Lehmann
2011-03-22 6:28 ` Nicolas Morey-Chaisemartin
2011-07-14 18:33 ` funeeldy
2011-07-15 19:27 ` Jens Lehmann
2011-07-15 20:32 ` Marlene Cote
2011-07-15 21:41 ` Jens Lehmann
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D87B51A.4060609@web.de \
--to=jens.lehmann@web.de \
--cc=devel-git@morey-chaisemartin.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
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 NNTP newsgroup(s).