From: Junio C Hamano <gitster@pobox.com>
To: "Yin Ping" <pkufranky@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
Date: Sun, 04 Nov 2007 03:41:08 -0800 [thread overview]
Message-ID: <7vmytus0ff.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <46dff0320711040145k1edb1fcaq1daa5469c1158e81@mail.gmail.com> (Yin Ping's message of "Sun, 4 Nov 2007 17:45:41 +0800")
"Yin Ping" <pkufranky@gmail.com> writes:
> In both case, i think the user should be notified about the inconsistence.
> My patch given in the first letter handles this by two warning messages as
> follows (where $name is module name)
>
> + cd $name >&/dev/null || { echo " Warning: fail to
> chdir to $name" && exit; }
My point was that it is wrong to make this "you do not have that
submodule checked out" a warning.
Think about somebody who does _not_ care about that particular
submodule. He is working on one branch, and tries to merge
another branch that has some interesting changes outside the
submodule, but that branch also has updates to the submodule.
As he is _not_ interested in the submodule, he does not have it
checked out. He has not changed the commit bound in his index
with 160000 mode bits for that submodule since the common
ancestor, either (that's what "he does not care about the
submodule" means).
The merge will take the submodule commit object name from the
other branches change, just like the ordinary three-way merge
rule would do (one side changed, the other did not do anything,
so take the change). Suppose some files in the project proper,
outside the submodule, had conflicts. He has an unmerged index,
that has the submodule already correctly merged. But other
parts of his index are unmerged. git-status would guide him
what are conflicting, and git-commit would show him what he
would be committing.
In that situation, all he needs to know, with respect to the
submodule, is that the submodule has been updated since his HEAD
(and that is given by the runstatus output). He does not _care_
about what the individual commits in the submodule were. It is
not an error that the information from the submodule cannot be
shown to him. He _chose_ to ignore the details of that
submodule by not checking it out to begin with.
Something like this, to be totally quiet, would be more
appropriate.
for name in $modules
do
(
... do the range, indexone, headone stuff
cd "$name" 2>/dev/null || exit 0
echo "* $name $headone...$indexone:"
... whatever log you show
) | sed ...
done
By the way, I do not know about the quoting issues with $modules
variable in the above illustration, as I am not (yet) discussing
about the implementation level of details.
next prev parent reply other threads:[~2007-11-04 11:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-02 11:53 [PATCH] status&commit: Teach them to show commits of modified submodules Ping Yin
2007-11-02 20:29 ` Junio C Hamano
2007-11-02 23:50 ` Yin Ping
2007-11-03 0:01 ` Junio C Hamano
2007-11-04 9:22 ` Yin Ping
2007-11-04 9:25 ` Yin Ping
2007-11-04 9:56 ` Yin Ping
[not found] ` <46dff0320711040145k1edb1fcaq1daa5469c1158e81@mail.gmail.com>
2007-11-04 11:41 ` Junio C Hamano [this message]
2007-11-04 13:17 ` Yin Ping
2007-11-06 2:22 ` Junio C Hamano
2007-11-07 15:20 ` Yin Ping
-- strict thread matches above, loose matches on Subject: below --
2007-11-10 19:27 Ping Yin
2007-11-10 19:55 ` Sven Verdoolaege
2007-11-10 20:00 ` Sven Verdoolaege
2007-11-11 5:30 ` Yin Ping
2007-11-10 21:14 ` Junio C Hamano
2007-11-11 6:18 ` Yin Ping
2007-11-11 20:34 ` Junio C Hamano
2007-11-12 5:38 ` Ping Yin
2007-11-12 7:26 ` Johannes Sixt
2007-11-12 9:51 ` Johannes Schindelin
2007-11-12 22:39 ` Junio C Hamano
2007-11-12 8:40 ` Johan Herland
2007-11-12 10:03 ` Johannes Sixt
2007-11-11 0:07 ` Lars Hjemli
2007-11-11 6:24 ` Yin Ping
2007-11-11 8:27 ` Lars Hjemli
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=7vmytus0ff.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=pkufranky@gmail.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).