What should "git submodule summary" give before an initial commit?

Subsystems: the rest

4 messages, 4 authors, 2016-06-15 · open the first message on its own page

What should "git submodule summary" give before an initial commit?

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:48:23

"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

Re: What should "git submodule summary" give before an initial commit?

From: Johan Herland <hidden>
Date: 2016-06-15 22:48:23

On Wednesday 03 March 2010, Junio C Hamano wrote:

quoted hunk

"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: Johan Herland <redacted>

If you're planning to revert 3deea89 (although the above patch suggests 
you're not), then please don't revert the t7401 testcases added by that 
commit. The testcase is useful in any case.


...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net

Re: What should "git submodule summary" give before an initial commit?

From: Jens Lehmann <hidden>
Date: 2016-06-15 22:48:23

Am 03.03.2010 22:58, schrieb Junio C Hamano:

quoted hunk

"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 <redacted>

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);

Re: What should "git submodule summary" give before an initial commit?

From: Sverre Rabbelier <hidden>
Date: 2016-06-15 22:48:23

Heya,

On Thu, Mar 4, 2010 at 01:36, Jens Lehmann [off-list ref] wrote:

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):

I think the problem is deeper than that: git doesn't work that great
if there's no HEAD yet. Some of our features don't work (as expected)
if there's no HEAD. For example, 'git reset' doesn't work, of course,
I can use 'git rm --cached .' to achieve the same effect (since all
staged changes are guaranteed to be adds), but its' not quite the
same. Perhaps it's an idea to look at how we handle not having a head
across the board and deal with it at a higher level? Something like
pretending we do have a HEAD that's pointing at the empty tree when on
an unborn branch might fix 'git reset' (although I'm sure there's all
kinds of objections to actually doing that, I'm not suggesting that's
what we should do, but that's the kind of solution I think we should
look at).

-- 
Cheers,

Sverre Rabbelier

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help