From: Jens Lehmann <Jens.Lehmann@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Ping Yin <pkufranky@gmail.com>, Jeff King <peff@peff.net>,
Johan Herland <johan@herland.net>,
A Large Angry SCM <gitzilla@gmail.com>, git <git@vger.kernel.org>
Subject: Re: What should "git submodule summary" give before an initial commit?
Date: Thu, 04 Mar 2010 01:36:58 +0100 [thread overview]
Message-ID: <4B8F00AA.5050007@web.de> (raw)
In-Reply-To: <7vhboxf4nx.fsf_-_@alter.siamese.dyndns.org>
Am 03.03.2010 22:58, schrieb Junio C Hamano:
> "git status" collects the changes for both the index (since HEAD) and the
> working tree files (since the index), summarizes and shows them. When it
> is run before the first commit is made, it uses a logic different from the
> one used in the normal case to gather the information on the index, as we
> don't have HEAD yet, i.e. instead of "diff-index HEAD", we would run
> "diff-index emtpy-tree".
>
> How should status.submodulesummary integrate into this framework?
>
> Currently, it blindly runs "git submodule summary", and it gives an extra
> error message about HEAD not being a commit, and people (me included)
> misguidedly have spent time on squelching the message.
>
> But I think that was _all wrong_. I do not think "git submodule summary"
> should fail even when you haven't made your first commit.
>
> If you are before the first commit, we say everything you have in the
> index is a change you are adding with your next commit (which will be your
> initial one). If you added a submodule commit to the index, shouldn't
> "git submodule summary" say "you'll be committing the addition of this
> subproject"? IOW, shouldn't we be comparing an empty tree to find added
> submodules, like this, when we haven't made the first commit?
>
> git-submodule.sh | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 5869c00..0397f9d 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -556,10 +556,10 @@ cmd_summary() {
> if rev=$(git rev-parse -q --verify --default HEAD ${1+"$1"})
> then
> head=$rev
> - shift
> + test $# = 0 || shift
> elif test -z "$1" -o "$1" = "HEAD"
> then
> - return
> + head=4b825dc642cb6eb9a060e54bf8d69288fbee4904
> else
> head="HEAD"
> fi
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Your patch fixes "git submodule summary" in a freshly created repo for me.
But to make "git status" with status.submodulesummary work as expected,
i need something like the following patch on top of current pu (because
"git submodule summary --cached HEAD" returns no changes in a freshly
created repo):
diff --git a/wt-status.c b/wt-status.c
index 5807fc3..6769c2e 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -459,11 +459,21 @@ static void wt_status_print_changed(struct wt_status *s)
wt_status_print_trailer(s);
}
-static void wt_status_print_submodule_summary(struct wt_status *s, int uncommitted)
+static void wt_status_print_submodule_summary(struct wt_status *s, int uncommitted, int initial)
{
struct child_process sm_summary;
char summary_limit[64];
char index[PATH_MAX];
+ const char *ref = NULL;
+ if (!uncommitted) {
+ if (s->amend)
+ ref = "HEAD^";
+ else
+ if (initial)
+ ref = "4b825dc642cb6eb9a060e54bf8d69288fbee4904";
+ else
+ ref = "HEAD";
+ }
const char *env[] = { index, NULL };
const char *argv[] = {
"submodule",
@@ -472,7 +482,7 @@ static void wt_status_print_submodule_summary(struct wt_status *s, int uncommitt
"--for-status",
"--summary-limit",
summary_limit,
- uncommitted ? NULL : (s->amend ? "HEAD^" : "HEAD"),
+ ref,
NULL
};
@@ -581,8 +591,8 @@ void wt_status_print(struct wt_status *s)
wt_status_print_unmerged(s);
wt_status_print_changed(s);
if (s->submodule_summary) {
- wt_status_print_submodule_summary(s, 0); /* staged */
- wt_status_print_submodule_summary(s, 1); /* unstaged */
+ wt_status_print_submodule_summary(s, 0, s->is_initial); /* staged */
+ wt_status_print_submodule_summary(s, 1, 0); /* unstaged */
}
if (s->show_untracked_files)
wt_status_print_untracked(s);
next prev parent reply other threads:[~2010-03-04 0:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-03 12:21 Latest master failing t7401 submodule tests A Large Angry SCM
2010-03-03 19:45 ` Junio C Hamano
2010-03-03 20:02 ` Jeff King
2010-03-03 20:32 ` Junio C Hamano
2010-03-03 20:42 ` Jeff King
2010-03-03 21:04 ` Junio C Hamano
2010-03-03 21:28 ` Junio C Hamano
2010-03-03 21:58 ` What should "git submodule summary" give before an initial commit? Junio C Hamano
2010-03-03 23:10 ` Johan Herland
2010-03-04 0:36 ` Jens Lehmann [this message]
2010-03-04 6:01 ` Sverre Rabbelier
2010-03-04 6:22 ` Junio C Hamano
2010-03-04 6:36 ` Sverre Rabbelier
2010-03-04 6:43 ` Junio C Hamano
2010-03-04 6:48 ` Sverre Rabbelier
2010-03-03 22:57 ` Latest master failing t7401 submodule tests Jeff King
2010-03-03 20:52 ` Junio C Hamano
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=4B8F00AA.5050007@web.de \
--to=jens.lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=gitzilla@gmail.com \
--cc=johan@herland.net \
--cc=peff@peff.net \
--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).