On Nov 11, 2007 5:14 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> * I think everbody preferes to have "On branch master" at the
> very beginning
Reasonable.
>
> * As I understand it, in the real life use,
> 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.
I think it's this kind of case in most open-source project. However,
in a company environment, superprojects may be not so super. A
superproject may bind very tightly with submodules (such as the html
template files which change very frequently) and the developer of a superproject
and its submodules may be the same guy(s). In these cases, a long list
of commits
for submodules are expected be reviewed when commiting the superproject.
>
> 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.
> 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 agree.
>
> 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
>
I have struggled between these two kinds of presentation and finally
choose the '<<<' one.
IMHO, '-/+' one each line will distract and less space/size efficient
(100 '+/-' for 100 lines of messages).
However, it's not a big matter. I'll change the presentation if
everyone prefers the
patch-like one.
> 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.
>
So following is ok?
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: sm1
# modified: sm2
# modified: sm3
#
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# modified: file1
#
# Submodules modifiled: sm1 sm2 sm3
#
# * sm1 354cd45...3f751e5:
# - one line message for C
# - one line message for B
# + one line message for D
# + one line message for E
# * sm2 354cd46...3f751e7:
# - one line message
# * sm3 354cd47...3f751e8:
# Warn: sm1 doesn't contains commit 354cd45
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# file2
#
--
Ping Yin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
