From: Junio C Hamano <gitster@pobox.com>
To: Ping Yin <pkufranky@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
Date: Sat, 10 Nov 2007 13:14:16 -0800 [thread overview]
Message-ID: <7vabpliz13.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <1194722863-14741-1-git-send-email-pkufranky@gmail.com> (Ping Yin's message of "Sun, 11 Nov 2007 03:27:43 +0800")
Ping Yin <pkufranky@gmail.com> writes:
> # submodule modifiled: sm1 sm2
> #
> # * sm1 354cd45...3f751e5:
> # <<<
> # one line message for C
> # one line message for B
> # >>>
> # one line message for D
> # one line message for E
> #
> # * sm2 5c8bfb5...ac46d84:
> # <<<
> # msg
> #
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # modified: sm1
> # modified: sm2
I think this presentation order is horrible.
* I think everbody preferes to have "On branch master" at the
very beginning, to avoid committing to a wrong branch by
mistake.
* As I understand it, in the real life use, there will be quite
many commits from the submodule updates when a new commit is
bound to a submodule in the superproject, as _the_ point of
having a submodule is to bind a more or less independent
project that progresses at quite a different pace as a
submodule to the superproject. In other words, by design,
the superproject can stay behind from the tip of subproject
and rebind it to a different commit only when there are
significant changes of the subproject that need to be there
to allow the other parts of the superproject (either
superproject itself or another submodule) to use the features
and/or fixes the submodule updates provides.
Which means it will not be uncommon have hundreds of "one
line message" for the submodules at the very beginning of the
commit log message buffer, and your prsentation order will
make that part overwhelm the overview of what changed _in_
the supermodule itself (the "Changes to be committed:"
lines), which gives the birds-eye view.
And I think it is more important to give the birds-eye view
of the supermodule itself first, when you are helping to
prepare a commit message for the supermodule. The user would
start the commit log for the superproject with "This updates
the new frotz feature. It uses the updated API from the
submodules A and B so we now use updated versions of them."
and then continue "Notable changes in submodule A are ...".
And the new part you are adding would help the user to write
the latter description.
I also find "<<< lines then >>> other lines" format very hard to
read. Maybe formatting it like this would make it a bit more
readable and more space efficient?
# * sm1 354cd45...3f751e5:
# - one line message for C
# - one line message for B
# + one line message for D
# + one line message for E
# * sm2 5c8bfb5...ac46d84:
# - msg
Note that if you swap the order and move this at the tail
(perhaps before "Untracked files:" section, if you do not have a
decent .gitignore set up), you can also lose the "submodules
modified: sm1 sm2" line and the blank line before it, which
would make the output even shorter without losing any useful
information.
next prev parent reply other threads:[~2007-11-10 21:14 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-10 19:27 [PATCH] status&commit: Teach them to show commits of modified submodules 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 [this message]
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-12 14:21 ` [PATCH] status&commit: Teach them to show submodule commit summary Ping Yin
2007-11-12 14:46 ` Ralf Wildenhues
2007-11-12 15:17 ` Ping Yin
2007-11-12 16:53 ` Brian Gernhardt
2007-11-12 15:37 ` Jakub Narebski
2007-11-12 15:46 ` Ping Yin
2007-11-12 15:59 ` Johannes Sixt
2007-11-12 16:12 ` Jakub Narebski
2007-11-12 16:42 ` Ping Yin
2007-11-12 16:13 ` Johannes Schindelin
2007-11-12 16:39 ` Ping Yin
2007-11-12 16:51 ` Johannes Sixt
2007-11-12 16:35 ` Ping Yin
2007-11-12 16:45 ` Johannes Sixt
2007-11-12 17:47 ` Lars Hjemli
2007-11-15 16:49 ` Ping Yin
2007-11-11 0:07 ` [PATCH] status&commit: Teach them to show commits of modified submodules Lars Hjemli
2007-11-11 6:24 ` Yin Ping
2007-11-11 8:27 ` Lars Hjemli
-- strict thread matches above, loose matches on Subject: below --
2007-11-02 11:53 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
2007-11-04 13:17 ` Yin Ping
2007-11-06 2:22 ` Junio C Hamano
2007-11-07 15:20 ` Yin Ping
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=7vabpliz13.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).