[PATCH] wt-status.c: Modified status message shown for a parent-less branch

[PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Kaartic Sivaraam]

The status message shown for a paren-less branch wasn't so
descriptive and was a little confusing.

The message has been changed to be more descriptive to users in
such a way that it clearly shows the state of the branch / repository.

This allows the users to be reminded that they are about to make
their initial commit which the previous message didn't seem to do
communicate well.

A few alternatives were,

* No commit yet
* Your current branch does not have any commits
* Current branch waiting for initial commit

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
---
 wt-status.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 0375484..7bfdde4 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1576,7 +1576,7 @@ static void wt_longstatus_print(struct wt_status *s)
 
 	if (s->is_initial) {
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
-		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
+		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Waiting for initial commit"));
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
 	}
 
@@ -1746,7 +1746,7 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)
 #define LABEL(string) (s->no_gettext ? (string) : _(string))
 
 	if (s->is_initial)
-		color_fprintf(s->fp, header_color, LABEL(N_("Initial commit on ")));
+		color_fprintf(s->fp, header_color, LABEL(N_("Waiting for initial commit on ")));
 
 	if (!strcmp(s->branch, "HEAD")) {
 		color_fprintf(s->fp, color(WT_STATUS_NOBRANCH, s), "%s",
-- 
2.7.4

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Kaartic Sivaraam]

The status message shown for a parent-less branch wasn't so
descriptive and was a little confusing.

The message has been changed to be more descriptive to users in
such a way that it clearly shows the state of the branch / repository.

This allows the users to be reminded that they are about to make
their initial commit which the previous message didn't seem to do
communicate well.

A few alternatives were,

* No commit yet
* Your current branch does not have any commits
* Current branch waiting for initial commit

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
---
 Corrected a little typo in the commit message


 wt-status.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 037548496..7bfdde46d 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1576,7 +1576,7 @@ static void wt_longstatus_print(struct wt_status
*s)
 
 	if (s->is_initial) {
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s",
"");
-		status_printf_ln(s, color(WT_STATUS_HEADER, s),
_("Initial commit"));
+		status_printf_ln(s, color(WT_STATUS_HEADER, s),
_("Waiting for initial commit"));
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s",
"");
 	}
 
@@ -1746,7 +1746,7 @@ static void wt_shortstatus_print_tracking(struct
wt_status *s)
 #define LABEL(string) (s->no_gettext ? (string) : _(string))
 
 	if (s->is_initial)
-		color_fprintf(s->fp, header_color, LABEL(N_("Initial
commit on ")));
+		color_fprintf(s->fp, header_color, LABEL(N_("Waiting
for initial commit on ")));
 
 	if (!strcmp(s->branch, "HEAD")) {
 		color_fprintf(s->fp, color(WT_STATUS_NOBRANCH, s),
"%s",
-- 
2.11.0

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Junio C Hamano]

Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:

>Subject: Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

$ git shortlog -20 --no-merges

may help learning the preferred style of writing the title.  We do
not say "[I] did this".  Instead we phrase things in imperative
mood, giving an order to the codebase to "become like so".  E.g.

    Subject: wt-status.c: rephrase "Initial commit" in "git status" output

or something like that.

> The status message shown for a paren-less branch wasn't so
> descriptive and was a little confusing.

s/paren/parent/; It was descritive enough, but the problem lied
elsewhere. It assumed that the user knows that "git status" message
is relative to the next commit the user creates from the state.

And it wasn't just "a little" confusing.

	"git status" indicated "Initial commit" when HEAD points at
	an unborn branch.  This message is shared with the commit
	log template "git commit" prepares for the user when
	creating a commit (i.e. "You are about to create the initial
	commit"), and is OK as long as the reader is aware of the
	nature of the message (i.e. it guides the user working
	toward the next commit), but was confusing to new users,
	especially the ones who do "git commit -m message" without
	having a chance to pay attention to the commit log template.

> The message has been changed to be more descriptive to users in
> such a way that it clearly shows the state of the branch / repository.

Again, not "This commit did X".

	Rephrase the message so that it is more clear that the state
	of the current branch (not the whole repository) is being
	described to remove this confusion.

> This allows the users to be reminded that they are about to make
> their initial commit which the previous message didn't seem to do
> communicate well.

And this paragraph becomes unnecessary.

> A few alternatives were,

s/were/considered were/;

>
> * No commit yet
> * Your current branch does not have any commits
> * Current branch waiting for initial commit
>
> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
> ---

Does this break "git commit", or is the update limited to "git
status"?

>  wt-status.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index 0375484..7bfdde4 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1576,7 +1576,7 @@ static void wt_longstatus_print(struct wt_status *s)
>  
>  	if (s->is_initial) {
>  		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
> -		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
> +		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Waiting for initial commit"));
>  		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
>  	}
>  
> @@ -1746,7 +1746,7 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)
>  #define LABEL(string) (s->no_gettext ? (string) : _(string))
>  
>  	if (s->is_initial)
> -		color_fprintf(s->fp, header_color, LABEL(N_("Initial commit on ")));
> +		color_fprintf(s->fp, header_color, LABEL(N_("Waiting for initial commit on ")));
>  
>  	if (!strcmp(s->branch, "HEAD")) {
>  		color_fprintf(s->fp, color(WT_STATUS_NOBRANCH, s), "%s",

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Kaartic Sivaraam]

On Sat, 2017-06-10 at 11:23 +0900, Junio C Hamano wrote:
> $ git shortlog -20 --no-merges
> 
> may help learning the preferred style of writing the title.  We do
> not say "[I] did this".  Instead we phrase things in imperative
> mood, giving an order to the codebase to "become like so".  E.g.
This style is a little new to me thus my commit message turned out to
be a repercussion of my own style (which, I guess, targets other
developers who read the log). Will be careful the next time :). Made
the requested changes except for a few doubts they raised (see comments
below).

> And it wasn't just "a little" confusing.
> 
> 	"git status" indicated "Initial commit" when HEAD points at
> 	an unborn branch.  This message is shared with the commit
> 	log template "git commit" prepares for the user when
> 	creating a commit (i.e. "You are about to create the initial
> 	commit"),
I didn't get that, where should I be seeing the line, "You are about to
create the initial commit" in the commit template ? I just saw "Initial
commit" in it.

> Does this break "git commit", or is the update limited to "git
> status"?
This does seem to be breaking 'git commit' as it seems to be using the
output of 'git status'. This change results in the following commit
template for the initial commit,

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
#
# Waiting for initial commit
#
# Changes to be committed:
#       new file:   test-file
#

Looks odd. Not sure how to fix this. Maybe on of the alternatives have
to be considered. "Your current branch does not have any commits" seems
a good one.

-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Kaartic Sivaraam]

On Sat, 2017-06-10 at 14:14 +0530, Kaartic Sivaraam wrote:
> Looks odd. 
Just to be more clear by "Looks odd" I mean that the new status message
looks odd in the commit template.

-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Jeff King]

On Sat, Jun 10, 2017 at 02:14:01PM +0530, Kaartic Sivaraam wrote:

> > Does this break "git commit", or is the update limited to "git
> > status"?
> This does seem to be breaking 'git commit' as it seems to be using the
> output of 'git status'. This change results in the following commit
> template for the initial commit,
> 
> # Please enter the commit message for your changes. Lines starting
> # with '#' will be ignored, and an empty message aborts the commit.
> # On branch master
> #
> # Waiting for initial commit
> #
> # Changes to be committed:
> #       new file:   test-file
> #
> 
> Looks odd. Not sure how to fix this. Maybe on of the alternatives have
> to be considered. "Your current branch does not have any commits" seems
> a good one.

We could also add an option to "struct wt_status" to differentiate the
two cases.

I had forgotten completely that this would affect git-commit. And that
explains the "Initial commit" text in the first place. This output
originated as the git-commit template message, and only later was moved
into the git-status command. And in the context of making a commit,
saying "This is the initial commit" makes a lot of sense.

And it probably does mean we want separate messages for status and
commit. One is "if you were to make a commit, it would be the first".
The other is "you are making the first commit".

-Peff

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Sat, Jun 10, 2017 at 02:14:01PM +0530, Kaartic Sivaraam wrote:
> ...
>> # Please enter the commit message for your changes. Lines starting
>> # with '#' will be ignored, and an empty message aborts the commit.
>> # On branch master
>> #
>> # Waiting for initial commit
>> #
>> # Changes to be committed:
>> #       new file:   test-file
>> #
>> 
>> Looks odd. Not sure how to fix this. Maybe on of the alternatives have
>> to be considered. "Your current branch does not have any commits" seems
>> a good one.
>
> We could also add an option to "struct wt_status" to differentiate the
> two cases.
>
> I had forgotten completely that this would affect git-commit. And that
> explains the "Initial commit" text in the first place. This output
> originated as the git-commit template message, and only later was moved
> into the git-status command. And in the context of making a commit,
> saying "This is the initial commit" makes a lot of sense.
>
> And it probably does mean we want separate messages for status and
> commit. One is "if you were to make a commit, it would be the first".
> The other is "you are making the first commit".

Again, you said what I wanted to say in my review comment a lot
better than I managed to say ;-)

When the current message "Initial commit" is read in the context
together with "Changes to be committed", etc., by users of "git
commit" who do not use the "-m message" option, it is clear that
these are talking about the commit the user is about to make.  

The confusion factor that triggered the discussion in the thread
that resulted in this patch exists because the output from "git
status" uses phrases that are designed to guide the user in working
toward creating the next commit on the branch, even though the user
may not be thinking in terms of "what would happen when I say
'commit' now?"

And I do not think the potential confusion is limited to "Initial
commit" from that point of view.  The files listed in "Changes to be
committed" list are not files to be "committed", UNLESS the user is
aware that s/he is asking "what would happen when I say 'commit'
now?".  When the question is "what is the status of my working area?",
that phrase in the section header is suboptimal.

Adding a bit to "struct wt_status" is a good first step to allow all
three (i.e. in addition to "Initial commit" and "Changes to be
committed", "Changes not staged for commit" is the other one that
shares this potential confusion factor) to be phrased in a way that
is more appropriate in an answer to the question "what is the status
of my working area?", I would think.

Thanks.

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Philip Oakley]

From: "Kaartic Sivaraam" <kaarticsivaraam91196@gmail.com>
> On Sat, 2017-06-10 at 11:23 +0900, Junio C Hamano wrote:
>> $ git shortlog -20 --no-merges
>>
>> may help learning the preferred style of writing the title. We do
>> not say "[I] did this". Instead we phrase things in imperative
>> mood, giving an order to the codebase to "become like so". E.g.
> This style is a little new to me thus my commit message turned out to
> be a repercussion of my own style (which, I guess, targets other
> developers who read the log). Will be careful the next time :). Made
> the requested changes except for a few doubts they raised (see comments
> below).
>
>> And it wasn't just "a little" confusing.
>>
>> "git status" indicated "Initial commit" when HEAD points at
>> an unborn branch. This message is shared with the commit
>> log template "git commit" prepares for the user when
>> creating a commit (i.e. "You are about to create the initial
>> commit"),
> I didn't get that, where should I be seeing the line, "You are about to
> create the initial commit" in the commit template ? I just saw "Initial
> commit" in it.
>
>> Does this break "git commit", or is the update limited to "git
>> status"?
> This does seem to be breaking 'git commit' as it seems to be using the
> output of 'git status'. This change results in the following commit
> template for the initial commit,
>
> # Please enter the commit message for your changes. Lines starting
> # with '#' will be ignored, and an empty message aborts the commit.
> # On branch master
> #
> # Waiting for initial commit

To me this sounds perfectly natural. It is the current status. The line will 
be ignored by the commit message anyway unless the user edits the start of 
the line.

At most it is a feeling that maybe we should provide an imperative 
statement, but even then, it's still stating the obvious (which is normally 
a bad thing). If the user is adding a .gitignore file then the commit 
message should say so, etc. Maybe the "Initial commit" is meant to be the 
default (by convention) separator, or its just a convention we've become 
used to.

> #
> # Changes to be committed:
> # new file: test-file
> #
>
> Looks odd. Not sure how to fix this. Maybe on of the alternatives have
> to be considered. "Your current branch does not have any commits" seems
> a good one.
>
> -- 
> Regards,
> Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

--
Philip 

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Kaartic Sivaraam]

On Sat, 2017-06-10 at 20:02 +0900, Junio C Hamano wrote:
> Again, you said what I wanted to say in my review comment a lot
> better than I managed to say ;-)
> 
> When the current message "Initial commit" is read in the context
> together with "Changes to be committed", etc., by users of "git
> commit" who do not use the "-m message" option, it is clear that
> these are talking about the commit the user is about to make.  
> 
> The confusion factor that triggered the discussion in the thread
> that resulted in this patch exists because the output from "git
> status" uses phrases that are designed to guide the user in working
> toward creating the next commit on the branch, even though the user
> may not be thinking in terms of "what would happen when I say
> 'commit' now?"
> 
> And I do not think the potential confusion is limited to "Initial
> commit" from that point of view.  The files listed in "Changes to be
> committed" list are not files to be "committed", UNLESS the user is
> aware that s/he is asking "what would happen when I say 'commit'
> now?".  When the question is "what is the status of my working
> area?",
> that phrase in the section header is suboptimal.
> 
> Adding a bit to "struct wt_status" is a good first step to allow all
> three (i.e. in addition to "Initial commit" and "Changes to be
> committed", "Changes not staged for commit" is the other one that
> shares this potential confusion factor) to be phrased in a way that
> is more appropriate in an answer to the question "what is the status
> of my working area?", I would think.
> 
> Thanks.
> 
It seems that the current change has to be discarded altogether and
further the change required doesn't look trivial. This seems to warrant
some bit of research of the code base. As a first step I would like to
know which part of the code base creates the commit template. I guess
much can't be done without knowing how it's created.

-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Junio C Hamano]

Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:

>> Adding a bit to "struct wt_status" is a good first step to allow all
>> three (i.e. in addition to "Initial commit" and "Changes to be
>> committed", "Changes not staged for commit" is the other one that
>> shares this potential confusion factor) to be phrased in a way that
>> is more appropriate in an answer to the question "what is the status
>> of my working area?", I would think.
>> 
>> Thanks.
>> 
> It seems that the current change has to be discarded altogether and
> further the change required doesn't look trivial. This seems to warrant
> some bit of research of the code base. As a first step I would like to
> know which part of the code base creates the commit template. I guess
> much can't be done without knowing how it's created.

Perhaps something along this line (warning: not even compile
tested)?

 builtin/commit.c |  1 +
 wt-status.c      | 15 ++++++++++++---
 wt-status.h      |  1 +
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index da1ba4c862..ffb2d71d3d 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1652,6 +1652,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 		usage_with_options(builtin_commit_usage, builtin_commit_options);
 
 	status_init_config(&s, git_commit_config);
+	s.commit_template = 1;
 	status_format = STATUS_FORMAT_NONE; /* Ignore status.short */
 	s.colopts = 0;
 
diff --git a/wt-status.c b/wt-status.c
index 25aafc35c8..006aaf9e76 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -196,7 +196,10 @@ static void wt_longstatus_print_cached_header(struct wt_status *s)
 {
 	const char *c = color(WT_STATUS_HEADER, s);
 
-	status_printf_ln(s, c, _("Changes to be committed:"));
+	if (s->commit_template)
+		status_printf_ln(s, c, _("Changes to be committed:"));
+	else
+		status_printf_ln(s, c, _("Changes already in the index:"));
 	if (!s->hints)
 		return;
 	if (s->whence != FROM_COMMIT)
@@ -214,7 +217,10 @@ static void wt_longstatus_print_dirty_header(struct wt_status *s,
 {
 	const char *c = color(WT_STATUS_HEADER, s);
 
-	status_printf_ln(s, c, _("Changes not staged for commit:"));
+	if (s->commit_template)
+		status_printf_ln(s, c, _("Changes not staged for commit:"));
+	else
+		status_printf_ln(s, c, _("Changes not yet in the index:"));
 	if (!s->hints)
 		return;
 	if (!has_deleted)
@@ -1578,7 +1584,10 @@ static void wt_longstatus_print(struct wt_status *s)
 
 	if (s->is_initial) {
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
-		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
+		status_printf_ln(s, color(WT_STATUS_HEADER, s),
+				 s->commit_template
+				 ? _("Initial commit")
+				 : _("No commit yet on the branch"));
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
 	}
 
diff --git a/wt-status.h b/wt-status.h
index 8a3864783b..17f72f2346 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -77,6 +77,7 @@ struct wt_status {
 	unsigned colopts;
 	int null_termination;
 	int show_branch;
+	int commit_template;
 	int hints;
 
 	enum wt_status_format status_format;

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Jeff King]

On Mon, Jun 12, 2017 at 11:28:56AM -0700, Junio C Hamano wrote:

> Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:
> 
> >> Adding a bit to "struct wt_status" is a good first step to allow all
> >> three (i.e. in addition to "Initial commit" and "Changes to be
> >> committed", "Changes not staged for commit" is the other one that
> >> shares this potential confusion factor) to be phrased in a way that
> >> is more appropriate in an answer to the question "what is the status
> >> of my working area?", I would think.
> >> 
> >> Thanks.
> >> 
> > It seems that the current change has to be discarded altogether and
> > further the change required doesn't look trivial. This seems to warrant
> > some bit of research of the code base. As a first step I would like to
> > know which part of the code base creates the commit template. I guess
> > much can't be done without knowing how it's created.
> 
> Perhaps something along this line (warning: not even compile
> tested)?

So I think the addition of the bit here is obviously correct, and I'm
not opposed to the idea of giving wt-status more information so that it
can make better messages. But I'm not sure it's actually helping for
some of these cases. E.g.:

> -	status_printf_ln(s, c, _("Changes not staged for commit:"));
> +	if (s->commit_template)
> +		status_printf_ln(s, c, _("Changes not staged for commit:"));
> +	else
> +		status_printf_ln(s, c, _("Changes not yet in the index:"));

I think "staged for commit" still makes perfect sense even when we are
just asking "what's the current status" and not "what would it look like
if I were to commit".

And avoiding the word "index" is worth-while here, I think. I am not in
general of the "let's hide the index" camp" but it is a technical term.
If we can say the same thing in a way that is understood both by people
who know what the index is and people who do not, that seems like a win.

> -	status_printf_ln(s, c, _("Changes to be committed:"));
> +	if (s->commit_template)
> +		status_printf_ln(s, c, _("Changes to be committed:"));
> +	else
> +		status_printf_ln(s, c, _("Changes already in the index:"));

This one is less obvious, because "to be committed" more strongly
implies making an actual commit. At the same time, I don't think it's
unclear what it means in the context of status. It could be "Changes
staged for commit" to match the other "not staged" message, though I
think I prefer the existing wording.

> @@ -1578,7 +1584,10 @@ static void wt_longstatus_print(struct wt_status *s)
>  
>  	if (s->is_initial) {
>  		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
> -		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
> +		status_printf_ln(s, color(WT_STATUS_HEADER, s),
> +				 s->commit_template
> +				 ? _("Initial commit")
> +				 : _("No commit yet on the branch"));

This one I think is an improvement. :)

-Peff

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> .... But I'm not sure it's actually helping for
> some of these cases. E.g.:
>
>> -	status_printf_ln(s, c, _("Changes not staged for commit:"));
>> +	if (s->commit_template)
>> +		status_printf_ln(s, c, _("Changes not staged for commit:"));
>> +	else
>> +		status_printf_ln(s, c, _("Changes not yet in the index:"));
>
> I think "staged for commit" still makes perfect sense even when we are
> just asking "what's the current status" and not "what would it look like
> if I were to commit".
>
> And avoiding the word "index" is worth-while here, I think. I am not in
> general of the "let's hide the index" camp" but it is a technical term.
> If we can say the same thing in a way that is understood both by people
> who know what the index is and people who do not, that seems like a win.

I do not mind "Changes not staged yet:".  The point was not about
getting rid of "stage" but about not mentioning "commit", because
stepping back a bit, if the readers are prepared to accept these
messages in the mindset that they are guiding them toward their next
commit, "I find 'Initial commit' confusing" would not have been an
issue in the first place.

>> -	status_printf_ln(s, c, _("Changes to be committed:"));
>> +	if (s->commit_template)
>> +		status_printf_ln(s, c, _("Changes to be committed:"));
>> +	else
>> +		status_printf_ln(s, c, _("Changes already in the index:"));
>
> This one is less obvious, because "to be committed" more strongly
> implies making an actual commit.

Again, I do not mind "Changes already staged:" too much.

If we can get rid of 'yet' and 'already' from the above two, that
would be even better.  The point of the exercise is to be understood
by those who do not think in terms of 'preparing for the next commit',
so 'yet', 'already', 'to be committed' are all counter-productive
for that goal.  Those who accept the 'description of the current
state in the context of preparing for the next commit' are not the
ones we are trying to help with the suggested three changes.

>> @@ -1578,7 +1584,10 @@ static void wt_longstatus_print(struct wt_status *s)
>>  
>>  	if (s->is_initial) {
>>  		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
>> -		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
>> +		status_printf_ln(s, color(WT_STATUS_HEADER, s),
>> +				 s->commit_template
>> +				 ? _("Initial commit")
>> +				 : _("No commit yet on the branch"));
>
> This one I think is an improvement. :)
>
> -Peff

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Jeff King]

On Mon, Jun 12, 2017 at 02:31:25PM -0700, Junio C Hamano wrote:

> >> -	status_printf_ln(s, c, _("Changes not staged for commit:"));
> >> +	if (s->commit_template)
> >> +		status_printf_ln(s, c, _("Changes not staged for commit:"));
> >> +	else
> >> +		status_printf_ln(s, c, _("Changes not yet in the index:"));
> >
> > I think "staged for commit" still makes perfect sense even when we are
> > just asking "what's the current status" and not "what would it look like
> > if I were to commit".
> >
> > And avoiding the word "index" is worth-while here, I think. I am not in
> > general of the "let's hide the index" camp" but it is a technical term.
> > If we can say the same thing in a way that is understood both by people
> > who know what the index is and people who do not, that seems like a win.
> 
> I do not mind "Changes not staged yet:".  The point was not about
> getting rid of "stage" but about not mentioning "commit", because
> stepping back a bit, if the readers are prepared to accept these
> messages in the mindset that they are guiding them toward their next
> commit, "I find 'Initial commit' confusing" would not have been an
> issue in the first place.

I think the difference is that "Initial commit" is talking about a
_specific_ commit. If we're not working on one, it doesn't make much
sense. But "staged for commit" is not necessarily talking about a
specific commit; we are talking about the purpose of staging something
in general. You could equally well say "staged for committing" (though I
think the shorter word sounds more natural).

Likewise with "to be committed".

> If we can get rid of 'yet' and 'already' from the above two, that
> would be even better.  The point of the exercise is to be understood
> by those who do not think in terms of 'preparing for the next commit',
> so 'yet', 'already', 'to be committed' are all counter-productive
> for that goal.  Those who accept the 'description of the current
> state in the context of preparing for the next commit' are not the
> ones we are trying to help with the suggested three changes.

I agree that is the goal. My point was that the existing messages are OK
even if you aren't thinking of preparing for the next commit. Saying
"this is in the index" and "this is staged" are synonyms. Saying "this
is staged for commit" is likewise a synonym, unless there is some other
reason we stage things.

-Peff

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Kaartic Sivaraam]

On Mon, 2017-06-12 at 17:37 -0400, Jeff King wrote:
> On Mon, Jun 12, 2017 at 02:31:25PM -0700, Junio C Hamano wrote:
> > > I think "staged for commit" still makes perfect sense even when
> > > we are
> > > just asking "what's the current status" and not "what would it
> > > look like
> > > if I were to commit".
> > > 
> > > And avoiding the word "index" is worth-while here, I think. I am
> > > not in
> > > general of the "let's hide the index" camp" but it is a technical
> > > term.
> > > If we can say the same thing in a way that is understood both by
> > > people
> > > who know what the index is and people who do not, that seems like
> > > a win.
> > 
> > I do not mind "Changes not staged yet:".  The point was not about
> > getting rid of "stage" but about not mentioning "commit", because
> > stepping back a bit, if the readers are prepared to accept these
> > messages in the mindset that they are guiding them toward their
> > next
> > commit, "I find 'Initial commit' confusing" would not have been an
> > issue in the first place.
> 
> I think the difference is that "Initial commit" is talking about a
> _specific_ commit. If we're not working on one, it doesn't make much
> sense. But "staged for commit" is not necessarily talking about a
> specific commit; we are talking about the purpose of staging
> something
> in general. You could equally well say "staged for committing"
> (though I
> think the shorter word sounds more natural).
> 
> Likewise with "to be committed".
> 
> > If we can get rid of 'yet' and 'already' from the above two, that
> > would be even better.  The point of the exercise is to be
> > understood
> > by those who do not think in terms of 'preparing for the next
> > commit',
> > so 'yet', 'already', 'to be committed' are all counter-productive
> > for that goal.  Those who accept the 'description of the current
> > state in the context of preparing for the next commit' are not the
> > ones we are trying to help with the suggested three changes.
> 
> I agree that is the goal. My point was that the existing messages are
> OK
> even if you aren't thinking of preparing for the next commit. Saying
> "this is in the index" and "this is staged" are synonyms. Saying
> "this
> is staged for commit" is likewise a synonym, unless there is some
> other
> reason we stage things.
> 
> -Peff
What about, "not making any assumptions" about what the user would
think when he views the output of `git status` ? Why not try some
general messages like, 

* Staged changes
* Unstaged changes

instead of the messages such as 

* Changes to be committed, Changes already in the index
* Changes not staged for commit, Changes not yet in the index

which seem to make assumptions about the user who view the output ?

A typical patch could be found below,

diff --git a/builtin/commit.c b/builtin/commit.c
index 1d805f5da..3ed8e40bc 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1364,6 +1364,7 @@ int cmd_status(int argc, const char **argv, const
char *prefix)
 		usage_with_options(builtin_status_usage,
builtin_status_options);
 
 	status_init_config(&s, git_status_config);
+	s.commit_template = 1;
 	argc = parse_options(argc, argv, prefix,
 			     builtin_status_options,
 			     builtin_status_usage, 0);
diff --git a/wt-status.c b/wt-status.c
index 037548496..55a7bd757 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -196,9 +196,14 @@ static void
wt_longstatus_print_cached_header(struct wt_status *s)
 {
 	const char *c = color(WT_STATUS_HEADER, s);
 
-	status_printf_ln(s, c, _("Changes to be committed:"));
+	if (s->commit_template)
+		status_printf_ln(s, c, _("Changes to be committed:"));
+	else
+		status_printf_ln(s, c, _("Staged changes:"));
+
 	if (!s->hints)
 		return;
+
 	if (s->whence != FROM_COMMIT)
 		; /* NEEDSWORK: use "git reset --unresolve"??? */
 	else if (!s->is_initial)
@@ -214,7 +219,11 @@ static void
wt_longstatus_print_dirty_header(struct wt_status *s,
 {
 	const char *c = color(WT_STATUS_HEADER, s);
 
-	status_printf_ln(s, c, _("Changes not staged for commit:"));
+	if (s->commit_template)
+		status_printf_ln(s, c, _("Changes not staged for
commit:"));
+	else
+		status_printf_ln(s, c, _("Unstaged changes:"));
+
 	if (!s->hints)
 		return;
 	if (!has_deleted)
@@ -1576,7 +1585,10 @@ static void wt_longstatus_print(struct wt_status
*s)
 
 	if (s->is_initial) {
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s",
"");
-		status_printf_ln(s, color(WT_STATUS_HEADER, s),
_("Initial commit"));
+		status_printf_ln(s, color(WT_STATUS_HEADER, s),
+				 s->commit_template
+				 ? _("Initial commit")
+				 : _("No commits yet on the branch"));
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s",
"");
 	}
 
diff --git a/wt-status.h b/wt-status.h
index 6018c627b..38bb24ef3 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -77,6 +77,7 @@ struct wt_status {
 	unsigned colopts;
 	int null_termination;
 	int show_branch;
+	int commit_template;
 	int hints;
 
 	enum wt_status_format status_format;

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Jeff King]

On Thu, Jun 15, 2017 at 01:49:20PM +0530, Kaartic Sivaraam wrote:

> What about, "not making any assumptions" about what the user would
> think when he views the output of `git status` ? Why not try some
> general messages like, 
> 
> * Staged changes
> * Unstaged changes
> 
> instead of the messages such as 
> 
> * Changes to be committed, Changes already in the index
> * Changes not staged for commit, Changes not yet in the index
> 
> which seem to make assumptions about the user who view the output ?

Saying just "staged changes" is definitely accurate. I don't know if
some users would find that too terse, too. The phrase "not staged for
commit" gives more information if you don't know what "staged" means in
the Git world.

-Peff

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Samuel Lijin]

On Thu, Jun 15, 2017 at 4:42 AM, Jeff King <peff@peff.net> wrote:
>
> On Thu, Jun 15, 2017 at 01:49:20PM +0530, Kaartic Sivaraam wrote:
>
> > What about, "not making any assumptions" about what the user would
> > think when he views the output of `git status` ? Why not try some
> > general messages like,
> >
> > * Staged changes
> > * Unstaged changes
> >
> > instead of the messages such as
> >
> > * Changes to be committed, Changes already in the index
> > * Changes not staged for commit, Changes not yet in the index
> >
> > which seem to make assumptions about the user who view the output ?
>
> Saying just "staged changes" is definitely accurate. I don't know if
> some users would find that too terse, too. The phrase "not staged for
> commit" gives more information if you don't know what "staged" means in
> the Git world.

Perhaps there should be a message pointing people at documentation
explaining the index and staging terminology?

Offhand, this is something I was wondering about the other day - has
there ever been a discussion of what level of proficiency Git expects
of its users?

> -Peff

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Jeff King]

On Thu, Jun 15, 2017 at 07:43:17AM -0400, Samuel Lijin wrote:

> > Saying just "staged changes" is definitely accurate. I don't know if
> > some users would find that too terse, too. The phrase "not staged for
> > commit" gives more information if you don't know what "staged" means in
> > the Git world.

Oops, I meant to say "too terse, though". But it sounds like you got my
meaning.

> Perhaps there should be a message pointing people at documentation
> explaining the index and staging terminology?

Maybe. I wouldn't want this message to get too verbose. People see it a
lot. There advice.statusHints message is already pretty verbose (though
I turned it off myself years ago).

> Offhand, this is something I was wondering about the other day - has
> there ever been a discussion of what level of proficiency Git expects
> of its users?

There have been lots of discussions, but none that I can think of as
definitive.

I think the general strategy these days is to try to give hints via
advise() for confusing situations, and to make it possible for expert
users to turn those off.

In general, I think using words from "git help glossary" is OK, but when
we can use plainer language without loss of precision, that seems like a
good idea. That's just my personal opinion, though.

-Peff

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Kaartic Sivaraam]

On Thu, 2017-06-15 at 09:12 -0400, Jeff King wrote:
> On Thu, Jun 15, 2017 at 07:43:17AM -0400, Samuel Lijin wrote:
> 
> > > Saying just "staged changes" is definitely accurate. I don't know
> > > if
> > > some users would find that too terse, too. The phrase "not staged
> > > for
> > > commit" gives more information if you don't know what "staged"
> > > means in
> > > the Git world.
> 
> Oops, I meant to say "too terse, though". But it sounds like you got
> my
> meaning.
> 
From what I could get from this thread, I guess the current patch
stands something like the one below. I tried building it with the below
change, it seems to be having a little issue. I'm not sure why, it
seems to be working the other way round i.e., the message "No commits
yet on the branch" message is shown in the commit template and the
message "Initial commit" is shown when `git status` is invoked.

Also, let me know if any other change is required.

diff --git a/builtin/commit.c b/builtin/commit.c
index 1d805f5da..3ed8e40bc 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1364,6 +1364,7 @@ int cmd_status(int argc, const char **argv, const
char *prefix)
                usage_with_options(builtin_status_usage,
builtin_status_options);
 
        status_init_config(&s, git_status_config);
+       s.commit_template = 1;
        argc = parse_options(argc, argv, prefix,
                             builtin_status_options,
                             builtin_status_usage, 0);
diff --git a/wt-status.c b/wt-status.c
index 037548496..34aa1af66 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1576,7 +1576,10 @@ static void wt_longstatus_print(struct wt_status
*s)
 
        if (s->is_initial) {
                status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s",
"");
-               status_printf_ln(s, color(WT_STATUS_HEADER, s),
_("Initial commit"));
+               status_printf_ln(s, color(WT_STATUS_HEADER, s),
+                                s->commit_template
+                                ? _("Initial commit")
+                                : _("No commits yet on the branch"));
                status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s",
"");
        }
 
diff --git a/wt-status.h b/wt-status.h
index 6018c627b..782b2997f 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -76,6 +76,7 @@ struct wt_status {
        char color_palette[WT_STATUS_MAXSLOT][COLOR_MAXLEN];
        unsigned colopts;
        int null_termination;
+       int commit_template;
        int show_branch;
        int hints;

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

[Jeff King]

On Fri, Jun 16, 2017 at 04:06:48PM +0530, Kaartic Sivaraam wrote:

> From what I could get from this thread, I guess the current patch
> stands something like the one below. I tried building it with the below
> change, it seems to be having a little issue. I'm not sure why, it
> seems to be working the other way round i.e., the message "No commits
> yet on the branch" message is shown in the commit template and the
> message "Initial commit" is shown when `git status` is invoked.
> 
> Also, let me know if any other change is required.
> 
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 1d805f5da..3ed8e40bc 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1364,6 +1364,7 @@ int cmd_status(int argc, const char **argv, const
> char *prefix)
>                 usage_with_options(builtin_status_usage,
> builtin_status_options);
>  
>         status_init_config(&s, git_status_config);
> +       s.commit_template = 1;
>         argc = parse_options(argc, argv, prefix,
>                              builtin_status_options,
>                              builtin_status_usage, 0);

Wouldn't you want this in cmd_commit(), not cmd_status()?

-Peff

Re: [PATCH/Almost final] wt-status.c: Modified status message shown for a parent-less branch

[Kaartic Sivaraam]

On Fri, 2017-06-16 at 06:50 -0400, Jeff King wrote:
> Wouldn't you want this in cmd_commit(), not cmd_status()?
> 
That's right. I made a little mistake while trying to replicate a
change specified by Mr. Junio C. Hamano in a previous mail in this
thread. 

Seems there aren't any other changes required as far as I could see,
hence this mail will follow with an "almost final" patch.

--
Regards,
Kaartic

[PATCH/ALMOST FINAL] Contextually notify user about an initial commit

[Kaartic Sivaraam]

"git status" indicated "Initial commit" when HEAD points at
an unborn branch.  This message is shared with the commit
log template "git commit" prepares for the user when
creating a commit (i.e. "You are about to create the initial
commit"), and is OK as long as the reader is aware of the
nature of the message (i.e. it guides the user working
toward the next commit), but was confusing to new users,
especially the ones who do "git commit -m message" without
having a chance to pay attention to the commit log template.

The "Initial commit" indication wasn't an issue in the commit
template. Taking that into consideration, a good solution would
be to contextually use different messages to indicate the user
that there were no commits in this branch.

A few alternatives considered were,

* Waiting for initial commit
* Your current branch does not have any commits
* Current branch waiting for initial commit

Patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
---
 builtin/commit.c | 1 +
 wt-status.c      | 5 ++++-
 wt-status.h      | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 1d805f5da..0f36d2ac3 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1648,6 +1648,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 		usage_with_options(builtin_commit_usage, builtin_commit_options);
 
 	status_init_config(&s, git_commit_config);
+	s.commit_template = 1;
 	status_format = STATUS_FORMAT_NONE; /* Ignore status.short */
 	s.colopts = 0;
 
diff --git a/wt-status.c b/wt-status.c
index 037548496..34aa1af66 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1576,7 +1576,10 @@ static void wt_longstatus_print(struct wt_status *s)
 
 	if (s->is_initial) {
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
-		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
+		status_printf_ln(s, color(WT_STATUS_HEADER, s),
+				 s->commit_template
+				 ? _("Initial commit")
+				 : _("No commits yet on the branch"));
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
 	}
 
diff --git a/wt-status.h b/wt-status.h
index 6018c627b..782b2997f 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -76,6 +76,7 @@ struct wt_status {
 	char color_palette[WT_STATUS_MAXSLOT][COLOR_MAXLEN];
 	unsigned colopts;
 	int null_termination;
+	int commit_template;
 	int show_branch;
 	int hints;
 
-- 
2.11.0

Re: [PATCH/ALMOST FINAL] Contextually notify user about an initial commit

[Ævar Arnfjörð Bjarmason]

On Sun, Jun 18 2017, Kaartic Sivaraam jotted:

> "git status" indicated "Initial commit" when HEAD points at
> an unborn branch.  This message is shared with the commit
> log template "git commit" prepares for the user when
> creating a commit (i.e. "You are about to create the initial
> commit"), and is OK as long as the reader is aware of the
> nature of the message (i.e. it guides the user working
> toward the next commit), but was confusing to new users,
> especially the ones who do "git commit -m message" without
> having a chance to pay attention to the commit log template.
>
> The "Initial commit" indication wasn't an issue in the commit
> template. Taking that into consideration, a good solution would
> be to contextually use different messages to indicate the user
> that there were no commits in this branch.
>
> A few alternatives considered were,
>
> * Waiting for initial commit
> * Your current branch does not have any commits
> * Current branch waiting for initial commit
>
> Patch-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
> ---
>  builtin/commit.c | 1 +
>  wt-status.c      | 5 ++++-
>  wt-status.h      | 1 +
>  3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 1d805f5da..0f36d2ac3 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1648,6 +1648,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>  		usage_with_options(builtin_commit_usage, builtin_commit_options);
>
>  	status_init_config(&s, git_commit_config);
> +	s.commit_template = 1;
>  	status_format = STATUS_FORMAT_NONE; /* Ignore status.short */
>  	s.colopts = 0;
>
> diff --git a/wt-status.c b/wt-status.c
> index 037548496..34aa1af66 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1576,7 +1576,10 @@ static void wt_longstatus_print(struct wt_status *s)
>
>  	if (s->is_initial) {
>  		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
> -		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
> +		status_printf_ln(s, color(WT_STATUS_HEADER, s),
> +				 s->commit_template
> +				 ? _("Initial commit")
> +				 : _("No commits yet on the branch"));

Why not simply "No commits yet", saying "on the branch" is needlessy
duplicating information in the context of the status output in which
this is printed, i.e. now you have:

    $ ~/g/git/git-status
    On branch master

    No commits yet on the branch

    nothing to commit (create/copy files and use "git add" to track)

But we can just more succinctly say:

    $ ~/g/git/git-status
    On branch master

    No commits yet

    nothing to commit (create/copy files and use "git add" to track)

Since we've already pointed out that the user is on a branch.

Also, if something is worth fixing it's worth testing for, so you can
fix this test into the patch:

diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 79427840a4..b9532d201d 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -1608,4 +1608,15 @@ test_expect_success 'git commit -m will commit a staged but ignored submodule' '
        git config -f .gitmodules  --remove-section submodule.subname
 '
 
+test_expect_success 'No commits yet should be noted in status output' '
+       git init initial &&
+       cd initial &&
+       git status >output &&
+       test_i18ngrep "No commits yet" output &&
+       test_commit initial &&
+       git status >output &&
+       test_i18ngrep ! "No commits yet" output &&
+       test_i18ngrep "nothing.*to commit" output
+'
+
 test_done
diff --git a/wt-status.c b/wt-status.c
index 7991fd1098..f324ea20a6 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1582,7 +1582,7 @@ static void wt_longstatus_print(struct wt_status *s)
                status_printf_ln(s, color(WT_STATUS_HEADER, s),
                                 s->commit_template
                                 ? _("Initial commit")
-                                : _("No commits yet on the branch"));
+                                : _("No commits yet"));
                status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
        }


>  		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
>  	}
>
> diff --git a/wt-status.h b/wt-status.h
> index 6018c627b..782b2997f 100644
> --- a/wt-status.h
> +++ b/wt-status.h
> @@ -76,6 +76,7 @@ struct wt_status {
>  	char color_palette[WT_STATUS_MAXSLOT][COLOR_MAXLEN];
>  	unsigned colopts;
>  	int null_termination;
> +	int commit_template;
>  	int show_branch;
>  	int hints;

[PATCH 1/2] Contextually notify user about an initial commit

[Kaartic Sivaraam]

"git status" indicated "Initial commit" when HEAD points at
an unborn branch.  This message is shared with the commit
log template "git commit" prepares for the user when
creating a commit (i.e. "You are about to create the initial
commit"), and is OK as long as the reader is aware of the
nature of the message (i.e. it guides the user working
toward the next commit), but was confusing to new users,
especially the ones who do "git commit -m message" without
having a chance to pay attention to the commit log template.

The "Initial commit" indication wasn't an issue in the commit
template. Taking that into consideration, a good solution would
be to contextually use different messages to indicate the user
that there were no commits in this branch.

A few alternatives considered were,

* Waiting for initial commit
* Your current branch does not have any commits
* Current branch waiting for initial commit

Patch-derived-from: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
---
  Hope this would be final :)

 builtin/commit.c | 1 +
 wt-status.c      | 5 ++++-
 wt-status.h      | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 1d805f5da..0f36d2ac3 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1648,6 +1648,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 		usage_with_options(builtin_commit_usage, builtin_commit_options);
 
 	status_init_config(&s, git_commit_config);
+	s.commit_template = 1;
 	status_format = STATUS_FORMAT_NONE; /* Ignore status.short */
 	s.colopts = 0;
 
diff --git a/wt-status.c b/wt-status.c
index 037548496..e6a9ee34f 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1576,7 +1576,10 @@ static void wt_longstatus_print(struct wt_status *s)
 
 	if (s->is_initial) {
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
-		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
+		status_printf_ln(s, color(WT_STATUS_HEADER, s),
+				 s->commit_template
+				 ? _("Initial commit")
+				 : _("No commits yet"));
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
 	}
 
diff --git a/wt-status.h b/wt-status.h
index 6018c627b..782b2997f 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -76,6 +76,7 @@ struct wt_status {
 	char color_palette[WT_STATUS_MAXSLOT][COLOR_MAXLEN];
 	unsigned colopts;
 	int null_termination;
+	int commit_template;
 	int show_branch;
 	int hints;
 
-- 
2.11.0

[PATCH 2/2] Add test for the new status message

[Kaartic Sivaraam]

Patch-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
---
 t/t7508-status.sh | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index fb00e6d9b..e9337c728 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -1499,4 +1499,15 @@ test_expect_success 'git commit -m will commit a staged but ignored submodule' '
 	git config -f .gitmodules  --remove-section submodule.subname
 '
 
+test_expect_success 'No commits yet should be noted in status output' '
+       git init initial &&
+       cd initial &&
+       git status >output &&
+       test_i18ngrep "No commits yet" output &&
+       test_commit initial &&
+       git status >output &&
+       test_i18ngrep ! "No commits yet" output &&
+       test_i18ngrep "nothing.*to commit" output
+'
+
 test_done
-- 
2.11.0

[PATCH 2/2] Add test for the new status message

[Kaartic Sivaraam]

Patch-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
---

Resending as a continuation of previous patch

 t/t7508-status.sh | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index fb00e6d9b..e9337c728 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -1499,4 +1499,15 @@ test_expect_success 'git commit -m will commit a staged but ignored submodule' '
 	git config -f .gitmodules  --remove-section submodule.subname
 '
 
+test_expect_success 'No commits yet should be noted in status output' '
+       git init initial &&
+       cd initial &&
+       git status >output &&
+       test_i18ngrep "No commits yet" output &&
+       test_commit initial &&
+       git status >output &&
+       test_i18ngrep ! "No commits yet" output &&
+       test_i18ngrep "nothing.*to commit" output
+'
+
 test_done
-- 
2.11.0

Re: [PATCH 1/2] Contextually notify user about an initial commit

[Junio C Hamano]

Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:

> A few alternatives considered were,
>
> * Waiting for initial commit
> * Your current branch does not have any commits
> * Current branch waiting for initial commit
>

... "Decided to take the most succinct one." or something to
conclude what happend to these alternatives would be nice to spell
out as a conclusion here.

> Patch-derived-from: Junio C Hamano <gitster@pobox.com>

That's just "Helped-by:".

> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
> ---
>   Hope this would be final :)
>
>  builtin/commit.c | 1 +
>  wt-status.c      | 5 ++++-
>  wt-status.h      | 1 +
>  3 files changed, 6 insertions(+), 1 deletion(-)


Thanks.  
Have you run the full test suite after applying this patch?

Adjustment to existing tests to update their expectation would be a
good thing to have in this patch that would easily illustaret what
will change and how.

At least this would be needed; there may be other breakages.


diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 0b6da7ae1f..fa61b1a4ee 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -18,7 +18,7 @@ test_expect_success 'initial status' '
 	echo bongo bongo >file &&
 	git add file &&
 	git status >actual &&
-	test_i18ngrep "Initial commit" actual
+	test_i18ngrep "No commits yet" actual
 '
 
 test_expect_success 'fail initial amend' '

Re: [PATCH 2/2] Add test for the new status message

[Junio C Hamano]

Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:

> +test_expect_success 'No commits yet should be noted in status output' '
> +       git init initial &&
> +       cd initial &&
> +       git status >output &&
> +       test_i18ngrep "No commits yet" output &&
> +       test_commit initial &&
> +       git status >output &&
> +       test_i18ngrep ! "No commits yet" output &&
> +       test_i18ngrep "nothing.*to commit" output
> +'
> +

Do not "cd" in a test, without being in a subshell.  When other
people in the future want to add new tests to the end of this
script, the new test will end up running in the new subdirectory,
which is not something they should have to worry about.

	git checkout --orphan empty-branch &&
	git status >output &&
	test_i18ngrep "No commits yet" output &&
	...

perhaps?


>  test_done

Re: [PATCH/ALMOST FINAL] Contextually notify user about an initial commit

[Jeff King]

On Sun, Jun 18, 2017 at 10:34:59AM +0200, Ævar Arnfjörð Bjarmason wrote:

> Why not simply "No commits yet", saying "on the branch" is needlessy
> duplicating information in the context of the status output in which
> this is printed, i.e. now you have:
> 
>     $ ~/g/git/git-status
>     On branch master
> 
>     No commits yet on the branch
> 
>     nothing to commit (create/copy files and use "git add" to track)
> 
> But we can just more succinctly say:
> 
>     $ ~/g/git/git-status
>     On branch master
> 
>     No commits yet
> 
>     nothing to commit (create/copy files and use "git add" to track)
> 
> Since we've already pointed out that the user is on a branch.

I thought one of the points was to disambiguate the case of "no commits
yet in the repository" and "no commits yet on the branch". If we don't
care about making that distinction (or think that the mention of the
branch is enough to make it clear), then succinct is fine. I don't have
a strong opinion either way.

-Peff

Re: [PATCH/ALMOST FINAL] Contextually notify user about an initial commit

[Kaartic Sivaraam]

On Mon, 2017-06-19 at 05:10 -0400, Jeff King wrote:
> On Sun, Jun 18, 2017 at 10:34:59AM +0200, Ævar Arnfjörð Bjarmason
> wrote:
> 
> > Why not simply "No commits yet", saying "on the branch" is
> > needlessy
> > duplicating information in the context of the status output in
> > which
> > this is printed, i.e. now you have:
> > 
> >     $ ~/g/git/git-status
> >     On branch master
> > 
> >     No commits yet on the branch
> > 
> >     nothing to commit (create/copy files and use "git add" to
> > track)
> > Since we've already pointed out that the user is on a branch.
> 
> I thought one of the points was to disambiguate the case of "no
> commits
> yet in the repository" and "no commits yet on the branch". If we
> don't
> care about making that distinction (or think that the mention of the
> branch is enough to make it clear), then succinct is fine. I don't
> have
> a strong opinion either way.
> 
I had the same thought in the beginning but the sample output seemed to
make me think "The terse message was fine". I am unopinionated, too.
I'll stay with "No commits yet" for now until someone suggests to
change it due to confusion about whether it's a "No commits yet on the
branch" or it's a "No commits yet on this repository".

--
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

Re: [PATCH/ALMOST FINAL] Contextually notify user about an initial commit

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Sun, Jun 18, 2017 at 10:34:59AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> Why not simply "No commits yet", saying "on the branch" is needlessy
>> duplicating information in the context of the status output in which
>> this is printed, i.e. now you have:
>> 
>>     $ ~/g/git/git-status
>>     On branch master
>> 
>>     No commits yet on the branch
>> 
>>     nothing to commit (create/copy files and use "git add" to track)
>> 
>> But we can just more succinctly say:
>> 
>>     $ ~/g/git/git-status
>>     On branch master
>> 
>>     No commits yet
>> 
>>     nothing to commit (create/copy files and use "git add" to track)
>> 
>> Since we've already pointed out that the user is on a branch.
>
> I thought one of the points was to disambiguate the case of "no commits
> yet in the repository" and "no commits yet on the branch". If we don't
> care about making that distinction (or think that the mention of the
> branch is enough to make it clear), then succinct is fine. I don't have
> a strong opinion either way.

Neither do I.  As long as we always say "On branch X", the end
result would not make much difference with or without "on the
branch" at the end of this line, I would think.

Thanks.

Re: [PATCH 2/2] Add test for the new status message

[Kaartic Sivaraam]

On Sun, 2017-06-18 at 21:32 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:
> 
> > +test_expect_success 'No commits yet should be noted in status
> > output' '
> > +       git init initial &&
> > +       cd initial &&
> > +       git status >output &&
> > +       test_i18ngrep "No commits yet" output &&
> > +       test_commit initial &&
> > +       git status >output &&
> > +       test_i18ngrep ! "No commits yet" output &&
> > +       test_i18ngrep "nothing.*to commit" output
> > +'
> > +
> 
> Do not "cd" in a test, without being in a subshell.  When other
> people in the future want to add new tests to the end of this
> script, the new test will end up running in the new subdirectory,
> which is not something they should have to worry about.
> 
> 	git checkout --orphan empty-branch &&
> 	git status >output &&
> 	test_i18ngrep "No commits yet" output &&
> 	...
> 
> perhaps?
> 
> 
>  test_done
Fixed it. I wasn't aware of the guide lines for writing tests when I
used the patch from the thread blindly. I'll be careful to avoid that
in future.

Is there a way to test for the "Initial commit" message in the commit
template?

-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

Re: [PATCH 2/2] Add test for the new status message

[Jeff King]

On Mon, Jun 19, 2017 at 11:29:49PM +0530, Kaartic Sivaraam wrote:

> Is there a way to test for the "Initial commit" message in the commit
> template?

You can do "git commit --dry-run", which produces the template on
stdout.

That should be good enough for our purposes here, as it's the same code
that produces the text that goes into the editor template. If you really
wanted to test what the editor sees, you could do something like:

  GIT_EDITOR='cat >editor-input' git commit

but I don't think it's worth the trouble.

-Peff

Re: [PATCH 2/2] Add test for the new status message

[Kaartic Sivaraam]

On Mon, 2017-06-19 at 14:04 -0400, Jeff King wrote:
> On Mon, Jun 19, 2017 at 11:29:49PM +0530, Kaartic Sivaraam wrote:
> 
> > Is there a way to test for the "Initial commit" message in the
> > commit
> > template?
> 
> You can do "git commit --dry-run", which produces the template on
> stdout.
Thanks for the help :)

> 
> That should be good enough for our purposes here, as it's the same
> code
> that produces the text that goes into the editor template. If you
> really
> wanted to test what the editor sees, you could do something like:
> 
>   GIT_EDITOR='cat >editor-input' git commit
> 
> but I don't think it's worth the trouble.
> 
That's right. I thinks it's not worth the trouble too.

[PATCH 1/3] Contextually notify user about an initial commit

[Kaartic Sivaraam]

"git status" indicated "Initial commit" when HEAD points at
an unborn branch.  This message is shared with the commit
log template "git commit" prepares for the user when
creating a commit (i.e. "You are about to create the initial
commit"), and is OK as long as the reader is aware of the
nature of the message (i.e. it guides the user working
toward the next commit), but was confusing to new users,
especially the ones who do "git commit -m message" without
having a chance to pay attention to the commit log template.

The "Initial commit" indication wasn't an issue in the commit
template. Taking that into consideration, a good solution would
be to contextually use different messages to indicate the user
that there were no commits in this branch.

A few alternatives considered were,

* Waiting for initial commit
* Your current branch does not have any commits
* Current branch waiting for initial commit

The most succint one, "No commits yet", among the alternatives
was chosen.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
---
 builtin/commit.c | 1 +
 wt-status.c      | 5 ++++-
 wt-status.h      | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 1d805f5da..0f36d2ac3 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1648,6 +1648,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 		usage_with_options(builtin_commit_usage, builtin_commit_options);
 
 	status_init_config(&s, git_commit_config);
+	s.commit_template = 1;
 	status_format = STATUS_FORMAT_NONE; /* Ignore status.short */
 	s.colopts = 0;
 
diff --git a/wt-status.c b/wt-status.c
index 037548496..e6a9ee34f 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1576,7 +1576,10 @@ static void wt_longstatus_print(struct wt_status *s)
 
 	if (s->is_initial) {
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
-		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
+		status_printf_ln(s, color(WT_STATUS_HEADER, s),
+				 s->commit_template
+				 ? _("Initial commit")
+				 : _("No commits yet"));
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
 	}
 
diff --git a/wt-status.h b/wt-status.h
index 6018c627b..782b2997f 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -76,6 +76,7 @@ struct wt_status {
 	char color_palette[WT_STATUS_MAXSLOT][COLOR_MAXLEN];
 	unsigned colopts;
 	int null_termination;
+	int commit_template;
 	int show_branch;
 	int hints;
 
-- 
2.11.0

[PATCH 2/3] Update test(s) that used old status message

[Kaartic Sivaraam]

The tests that checked for old status message have been
updated to check for the new status message

Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
---
 t/t7501-commit.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 0b6da7ae1..fa61b1a4e 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -18,7 +18,7 @@ test_expect_success 'initial status' '
 	echo bongo bongo >file &&
 	git add file &&
 	git status >actual &&
-	test_i18ngrep "Initial commit" actual
+	test_i18ngrep "No commits yet" actual
 '
 
 test_expect_success 'fail initial amend' '
-- 
2.11.0

[PATCH 3/3] Add tests for the contextual initial status message

[Kaartic Sivaraam]

Also, fixed minor spacing issue

Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
---
 t/t7508-status.sh | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index fb00e6d9b..6cf3af9d9 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -1494,9 +1494,39 @@ EOF
 test_expect_success 'git commit -m will commit a staged but ignored submodule' '
 	git commit -uno -m message &&
 	git status -s --ignore-submodules=dirty >output &&
-	 test_i18ngrep ! "^M. sm" output &&
+	test_i18ngrep ! "^M. sm" output &&
 	git config --remove-section submodule.subname &&
 	git config -f .gitmodules  --remove-section submodule.subname
 '
 
+test_expect_success '"No commits yet" should be noted in status output' '
+	git checkout --orphan empty-branch-1 &&
+	git status >output &&
+	test_i18ngrep "No commits yet" output
+'
+
+test_expect_success '"No commits yet" should not be noted in status output' '
+	git checkout --orphan empty-branch-2 &&
+	test_commit test-commit-1 &&
+	git status >output &&
+	test_i18ngrep ! "No commits yet" output
+'
+
+test_expect_success '"Initial commit" should be noted in commit template' '
+	git checkout --orphan empty-branch-3 &&
+	touch to_be_committed_1 &&
+	git add to_be_committed_1 &&
+	git commit --dry-run >output &&
+	test_i18ngrep "Initial commit" output
+'
+
+test_expect_success '"Initial commit" should not be noted in commit template' '
+	git checkout --orphan empty-branch-4 &&
+	test_commit test-commit-2 &&
+	touch to_be_committed_2 &&
+	git add to_be_committed_2 &&
+	git commit --dry-run >output &&
+	test_i18ngrep ! "Initial commit" output
+'
+
 test_done
-- 
2.11.0

Re: [PATCH 1/3] Contextually notify user about an initial commit

[Ævar Arnfjörð Bjarmason]

On Tue, Jun 20 2017, Kaartic Sivaraam jotted:

> "git status" indicated "Initial commit" when HEAD points at
> an unborn branch.  This message is shared with the commit
> log template "git commit" prepares for the user when
> creating a commit (i.e. "You are about to create the initial
> commit"), and is OK as long as the reader is aware of the
> nature of the message (i.e. it guides the user working
> toward the next commit), but was confusing to new users,
> especially the ones who do "git commit -m message" without
> having a chance to pay attention to the commit log template.
>
> The "Initial commit" indication wasn't an issue in the commit
> template. Taking that into consideration, a good solution would
> be to contextually use different messages to indicate the user
> that there were no commits in this branch.
>
> A few alternatives considered were,
>
> * Waiting for initial commit
> * Your current branch does not have any commits
> * Current branch waiting for initial commit
>
> The most succint one, "No commits yet", among the alternatives
> was chosen.
>
> Helped-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

There's a few issues with these 3 patches I think should be fixed:

 * Let's do that spacing fix (unrelated fix) in its own commit.

 * You should add tests along with the code being changed, and
   especially change tests that would fail with your new code, otherwise
   you break bisection.

 * I think the commit message here could be shorter & clearer at the
   same time.

 * The commit message doesn't follow our usual format.

Other than that this looks good to me.

I've pushed a fixed version with those fixes to
help-kaartic-with-no-commits-yet on github.com/avar/git
(https://github.com/avar/git/tree/help-kaartic-with-no-commits-yet). You
could just submit that as a v2 pending any comments others might have.

That yields a 2 patch series, here pasted below for on-list review:

commit 23d792d8d3
Author: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
Date:   Tue Jun 20 08:32:20 2017 +0530

    status tests: fix a minor indenting issue

    Change the indentation from "\t " to "\t". This indenting issue was
    introduced when the test was added in commit
    1d2f393ac9 ("status/commit: show staged submodules regardless of
    ignore config", 2014-04-05).

    Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
    Helped-by: Junio C Hamano <gitster@pobox.com>
    Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
    Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 79427840a4..ebad377d68 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -1603,7 +1603,7 @@ EOF
 test_expect_success 'git commit -m will commit a staged but ignored submodule' '
 	git commit -uno -m message &&
 	git status -s --ignore-submodules=dirty >output &&
-	 test_i18ngrep ! "^M. sm" output &&
+	test_i18ngrep ! "^M. sm" output &&
 	git config --remove-section submodule.subname &&
 	git config -f .gitmodules  --remove-section submodule.subname
 '

commit d2eed0491c (HEAD -> help-kaartic-with-no-commits-yet, avar/help-kaartic-with-no-commits-yet)
Author: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
Date:   Tue Jun 20 08:32:18 2017 +0530

    status: contextually notify user about an initial commit

    Change the output of "status" to say "No commits yet" when "git
    status" is run on a fresh repo (or orphan branch), while retaining the
    current "Initial commit" message displayed in the template that's
    displayed in the editor when the initial commit is being authored.

    The existing "Initial commit" message makes sense for the commit
    template where we're making the initial commit, but is confusing when
    merely checking the status of a fresh repository without having any
    commits yet.

    Helped-by: Junio C Hamano <gitster@pobox.com>
    Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
    Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

diff --git a/builtin/commit.c b/builtin/commit.c
index e3c9e190b0..8d075c15a3 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1652,6 +1652,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 		usage_with_options(builtin_commit_usage, builtin_commit_options);

 	status_init_config(&s, git_commit_config);
+	s.commit_template = 1;
 	status_format = STATUS_FORMAT_NONE; /* Ignore status.short */
 	s.colopts = 0;

diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 0b6da7ae1f..fa61b1a4ee 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -18,7 +18,7 @@ test_expect_success 'initial status' '
 	echo bongo bongo >file &&
 	git add file &&
 	git status >actual &&
-	test_i18ngrep "Initial commit" actual
+	test_i18ngrep "No commits yet" actual
 '

 test_expect_success 'fail initial amend' '
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index ebad377d68..57a37f88a4 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -1608,4 +1608,34 @@ test_expect_success 'git commit -m will commit a staged but ignored submodule' '
 	git config -f .gitmodules  --remove-section submodule.subname
 '

+test_expect_success '"No commits yet" should be noted in status output' '
+	git checkout --orphan empty-branch-1 &&
+	git status >output &&
+	test_i18ngrep "No commits yet" output
+'
+
+test_expect_success '"No commits yet" should not be noted in status output' '
+	git checkout --orphan empty-branch-2 &&
+	test_commit test-commit-1 &&
+	git status >output &&
+	test_i18ngrep ! "No commits yet" output
+'
+
+test_expect_success '"Initial commit" should be noted in commit template' '
+	git checkout --orphan empty-branch-3 &&
+	touch to_be_committed_1 &&
+	git add to_be_committed_1 &&
+	git commit --dry-run >output &&
+	test_i18ngrep "Initial commit" output
+'
+
+test_expect_success '"Initial commit" should not be noted in commit template' '
+	git checkout --orphan empty-branch-4 &&
+	test_commit test-commit-2 &&
+	touch to_be_committed_2 &&
+	git add to_be_committed_2 &&
+	git commit --dry-run >output &&
+	test_i18ngrep ! "Initial commit" output
+'
+
 test_done
diff --git a/wt-status.c b/wt-status.c
index bf651f16fa..f324ea20a6 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1579,7 +1579,10 @@ static void wt_longstatus_print(struct wt_status *s)

 	if (s->is_initial) {
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
-		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
+		status_printf_ln(s, color(WT_STATUS_HEADER, s),
+				 s->commit_template
+				 ? _("Initial commit")
+				 : _("No commits yet"));
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
 	}

diff --git a/wt-status.h b/wt-status.h
index 8a3864783b..2389f08390 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -76,6 +76,7 @@ struct wt_status {
 	char color_palette[WT_STATUS_MAXSLOT][COLOR_MAXLEN];
 	unsigned colopts;
 	int null_termination;
+	int commit_template;
 	int show_branch;
 	int hints;

Re: [PATCH 1/3] Contextually notify user about an initial commit

[Kaartic Sivaraam]

Thanks for trying to help. A few comments regarding your suggestions.

>  * Let's do that spacing fix (unrelated fix) in its own commit.
> 
Ok. That's a good point.

>   * You should add tests along with the code being changed, and
>     especially change tests that would fail with your new code,
>     otherwise you break bisection.
> 
I'm not sure if the convention here is to keep tests along with change
it tests. I thought it would be better to separate them as they are
"separate" changes. They're separate because in case of any issues with
the test it should be possible to identify them separately. This isn't
possible when they are added along with the change. 

Further, adding them as a separate change change (commit) immediately
after the change it tests would ease the task of finding the change it
tests.

If the convention here, really, is to add tests along with the
change, I can't do anything but to follow it. I guess it should be
mentioned somewhere in the Documentation/SubmittingPatches. AFAIK, I
don't think it's mentioned there.

>  * I think the commit message here could be shorter & clearer at the
>    same time.
I don't think it's unclear. It's longer for the reason that follows.
The commit message was crafted based on the following guideline found
in Documentation/SubmittingPatches

> The body should provide a meaningful commit message, which:
> 
>   . explains the problem the change tries to solve, i.e. what is 
>     wrong with the current code without the change.
> 
>   . justifies the way the change solves the problem, i.e. why the
>     result with the change is better.
> 
>   . alternate solutions considered but discarded, if any.
> 
I don't think the new commit message follows this. Both the commit
messages are found below for comparison.

Old one
-------
> On Tue, Jun 20 2017, Kaartic Sivaraam jotted:
> 
>  "git status" indicated "Initial commit" when HEAD points at
>  an unborn branch.  This message is shared with the commit
>  log template "git commit" prepares for the user when
>  creating a commit (i.e. "You are about to create the initial
>  commit"), and is OK as long as the reader is aware of the
>  nature of the message (i.e. it guides the user working
>  toward the next commit), but was confusing to new users,
>  especially the ones who do "git commit -m message" without
>  having a chance to pay attention to the commit log template.
>  
>  The "Initial commit" indication wasn't an issue in the commit
>  template. Taking that into consideration, a good solution would
>  be to contextually use different messages to indicate the user
>  that there were no commits in this branch.
> 
>  A few alternatives considered were,
>  
>  * Waiting for initial commit
>  * Your current branch does not have any commits
>  * Current branch waiting for initial commit
>  
>  The most succint one, "No commits yet", among the alternatives
>  was chosen.
>  
>  Helped-by: Junio C Hamano <gitster@pobox.com>
>  Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
> 

New one
-------
>  status: contextually notify user about an initial commit
> 
>  Change the output of "status" to say "No commits yet" when "git
>  retaining the current "Initial commit" message displayed in the
>  template that's displayed in the editor when the initial commit is
>  being authored.
> 
>  The existing "Initial commit" message makes sense for the commit
>  template where we're making the initial commit, but is confusing 
>  when merely checking the status of a fresh repository without 
>  having any commits yet.
> 
>  Helped-by: Junio C Hamano <gitster@pobox.com>
>  Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
>  Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>  

>  * The commit message doesn't follow our usual format.
Could you be more specific about where it's not following the format?

-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

Re: [PATCH 1/3] Contextually notify user about an initial commit

[Ævar Arnfjörð Bjarmason]

On Tue, Jun 20 2017, Kaartic Sivaraam jotted:

> Thanks for trying to help. A few comments regarding your suggestions.
>
>> * Let's do that spacing fix (unrelated fix) in its own commit.
>>
> Ok. That's a good point.
>
>> * You should add tests along with the code being changed, and
>> especially change tests that would fail with your new code,
>>     otherwise you break bisection.
>>
> I'm not sure if the convention here is to keep tests along with change
> it tests. I thought it would be better to separate them as they are
> "separate" changes. They're separate because in case of any issues with
> the test it should be possible to identify them separately. This isn't
> possible when they are added along with the change.
>
> Further, adding them as a separate change change (commit) immediately
> after the change it tests would ease the task of finding the change it
> tests.
>
> If the convention here, really, is to add tests along with the
> change,I can't do anything but to follow it. I guess it should be
> mentioned somewhere in the Documentation/SubmittingPatches. AFAIK, I
> don't think it's mentioned there.

Right now 1/3 breaks the test suite. That's a big no-no, any given
commit should not break the test suite to not break bisecting.

But aside from that the general pattern we follow is that if code
behavior changes, tests for that new behavior go in the same commit.

>> * I think the commit message here could be shorter & clearer at the
>> same time.
> I don't think it's unclear. It's longer for the reason that follows.
> The commit message was crafted based on the following guideline found
> in Documentation/SubmittingPatches
>
>> The body should provide a meaningful commit message, which:
>>
>>  . explains the problem the change tries to solve, i.e. what is
>>     wrong with the current code without the change.
>>
>>  . justifies the way the change solves the problem, i.e. why the
>> result with the change is better.
>>
>>  . alternate solutions considered but discarded, if any.
>>
> I don't think the new commit message follows this. Both the commit
> messages are found below for comparison.
>
> Old one
> -------
>> On Tue, Jun 20 2017, Kaartic Sivaraam jotted:
>>
>>  "git status" indicated "Initial commit" when HEAD points at
>>  an unborn branch.This message is shared with the commit
>>  log template "git commit" prepares for the user when
>>  creating a commit (i.e. "You are about to create the initial
>>  commit"), and is OK as long as the reader is aware of the
>>  nature of the message (i.e. it guides the user working
>>  toward the next commit), but was confusing to new users,
>>  especially the ones who do "git commit -m message" without
>>  having a chance to pay attention to the commit log template.
>>
>>  The "Initial commit" indication wasn't an issue in the commit
>>  template. Taking that into consideration, a good solution would
>>  be to contextually use different messages to indicate the user
>>  that there were no commits in this branch.
>>
>>  A few alternatives considered were,
>>
>>  * Waiting for initial commit
>>  * Your current branch does not have any commits
>>  * Current branch waiting for initial commit
>>
>>  The most succint one, "No commits yet", among the alternatives
>>  was chosen.
>>
>>  Helped-by: Junio C Hamano <gitster@pobox.com>
>>  Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
>>
>
> New one
> -------
>>  status: contextually notify user about an initial commit
>>
>> Change the output of "status" to say "No commits yet" when "git
>>  retaining the current "Initial commit" message displayed in the
>>  template that's displayed in the editor when the initial commit is
>>  being authored.
>>
>> The existing "Initial commit" message makes sense for the commit
>> template where we're making the initial commit, but is confusing
>>  when merely checking the status of a fresh repository without
>>  having any commits yet.
>>
>> Helped-by: Junio C Hamano <gitster@pobox.com>
>> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>>
>
>> * The commit message doesn't follow our usual format.
> Could you be more specific about where it's not following the format?

Regarding the format: I was referring to the 'prefix the first line with
"area: "' part of SubmittingPatches, sorry for the brevity. I.e. your
--oneline output just yields "Contextually notify user about an initial
commit" but should be "status: <short summary>".

For the rest of the changes I made: I just found the current version
hard to read, most of the first paragraph is one big 8-line sentence,
after reading it over a few times and understanding what it was doing I
thought I'd rewrite it as a shorter version that was (hopefully) easier
to understand.

I dropped the "alternatives considered" because while it follows the
SubmittingPatches guidelines as-is, given other patches I've seen what
we eventually ended up picking for some trivial wording in a UI message
is probably better left to a mailing list search for anyone's that
curious rather than summarizing all the proposed alternatives in the
commit message.

Re: [PATCH 1/3] Contextually notify user about an initial commit

[Kaartic Sivaraam]

On Tue, 2017-06-20 at 16:41 +0200, Ævar Arnfjörð Bjarmason wrote:
> Right now 1/3 breaks the test suite. That's a big no-no, any given
> commit should not break the test suite to not break bisecting.
> 
> But aside from that the general pattern we follow is that if code
> behavior changes, tests for that new behavior go in the same commit.
> 
I did think of squashing the first two patches, anyway. Now the three
of them (except for that spacing fix) must be squashhed. Not a big
issue, anyway. I tweaked the suggested commit message a bit for the
following reason,

Ensure it follows the "describe problem, justify solution, mention
alternatives" pattern as it sounds good and natural. I wanted to keep
the alternatives as I found it to the commit message to be a more
appropriate place than the mailing list archives. This could induce
others who see it to do the same ;)

> 
> Regarding the format: I was referring to the 'prefix the first line
> with
> "area: "' part of SubmittingPatches, sorry for the brevity. I.e. your
> --oneline output just yields "Contextually notify user about an
> initial
> commit" but should be "status: <short summary>".
> 
That's a good one. I initially thought it was optional.

-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

[PATCH/FINAL] status: contextually notify user about an initial commit

[Kaartic Sivaraam]

The existing message, "Initial commit", makes sense for the commit template
notifying users that it's their initial commit, but is confusing when
merely checking the status of a fresh repository (or orphan branch)
without having any commits yet.

Change the output of "status" to say "No commits yet" when "git
status" is run on a fresh repo (or orphan branch), while retaining the
current "Initial commit" message displayed in the template that's
displayed in the editor when the initial commit is being authored.

A few alternatives considered were,

 * Waiting for initial commit
 * Your current branch does not have any commits
 * Current branch waiting for initial commit

The most succint one among the alternatives was chosen.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---

 The 'FINAL' part in the subject is just my opinion about 
 this patch

 builtin/commit.c  |  1 +
 t/t7501-commit.sh |  2 +-
 t/t7508-status.sh | 30 ++++++++++++++++++++++++++++++
 wt-status.c       |  5 ++++-
 wt-status.h       |  1 +
 5 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 8d1cac062..3d614a2ac 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1648,6 +1648,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 		usage_with_options(builtin_commit_usage, builtin_commit_options);
 
 	status_init_config(&s, git_commit_config);
+	s.commit_template = 1;
 	status_format = STATUS_FORMAT_NONE; /* Ignore status.short */
 	s.colopts = 0;
 
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 0b6da7ae1..fa61b1a4e 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -18,7 +18,7 @@ test_expect_success 'initial status' '
 	echo bongo bongo >file &&
 	git add file &&
 	git status >actual &&
-	test_i18ngrep "Initial commit" actual
+	test_i18ngrep "No commits yet" actual
 '
 
 test_expect_success 'fail initial amend' '
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 5edcc6edf..0ffa585e2 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -1499,4 +1499,34 @@ test_expect_success 'git commit -m will commit a staged but ignored submodule' '
 	git config -f .gitmodules  --remove-section submodule.subname
 '
 
+test_expect_success '"No commits yet" should be noted in status output' '
+	git checkout --orphan empty-branch-1 &&
+	git status >output &&
+	test_i18ngrep "No commits yet" output
+'
+
+test_expect_success '"No commits yet" should not be noted in status output' '
+	git checkout --orphan empty-branch-2 &&
+	test_commit test-commit-1 &&
+	git status >output &&
+	test_must_fail test_i18ngrep "No commits yet" output
+'
+
+test_expect_success '"Initial commit" should be noted in commit template' '
+	git checkout --orphan empty-branch-3 &&
+	touch to_be_committed_1 &&
+	git add to_be_committed_1 &&
+	git commit --dry-run >output &&
+	test_i18ngrep "Initial commit" output
+'
+
+test_expect_success '"Initial commit" should not be noted in commit template' '
+	git checkout --orphan empty-branch-4 &&
+	test_commit test-commit-2 &&
+	touch to_be_committed_2 &&
+	git add to_be_committed_2 &&
+	git commit --dry-run >output &&
+	test_must_fail test_i18ngrep "Initial commit" output
+'
+
 test_done
diff --git a/wt-status.c b/wt-status.c
index 068de38b5..a2e294bb2 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1578,7 +1578,10 @@ static void wt_longstatus_print(struct wt_status *s)
 
 	if (s->is_initial) {
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
-		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
+		status_printf_ln(s, color(WT_STATUS_HEADER, s),
+				 s->commit_template
+				 ? _("Initial commit")
+				 : _("No commits yet"));
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
 	}
 
diff --git a/wt-status.h b/wt-status.h
index 8a3864783..2389f0839 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -76,6 +76,7 @@ struct wt_status {
 	char color_palette[WT_STATUS_MAXSLOT][COLOR_MAXLEN];
 	unsigned colopts;
 	int null_termination;
+	int commit_template;
 	int show_branch;
 	int hints;
 
-- 
2.11.0

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

[Kaartic Sivaraam]

On Wed, 2017-06-21 at 08:07 +0530, Kaartic Sivaraam wrote:
> The existing message, "Initial commit", makes sense for the commit
> template
> notifying users that it's their initial commit, but is confusing when
> merely checking the status of a fresh repository (or orphan branch)
> without having any commits yet.
> 
> Change the output of "status" to say "No commits yet" when "git
> status" is run on a fresh repo (or orphan branch), while retaining
> the
> current "Initial commit" message displayed in the template that's
> displayed in the editor when the initial commit is being authored.
> 
> A few alternatives considered were,
> 
>  * Waiting for initial commit
>  * Your current branch does not have any commits
>  * Current branch waiting for initial commit
> 
> The most succint one among the alternatives was chosen.
> 
> Helped-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
> 
>  The 'FINAL' part in the subject is just my opinion about 
>  this patch
> 
Just for the note, the tests passed locally and all travis-ci builds
jobs succeeded except for the one in which the 'GITTEXT_POISON'
environment variable is enabled. I guess that isn't an issue, from what
I came to know while digging about it.

-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

[Ævar Arnfjörð Bjarmason]

On Wed, Jun 21 2017, Kaartic Sivaraam jotted:

> On Wed, 2017-06-21 at 08:07 +0530, Kaartic Sivaraam wrote:
>> The existing message, "Initial commit", makes sense for the commit
>> template
>> notifying users that it's their initial commit, but is confusing when
>> merely checking the status of a fresh repository (or orphan branch)
>> without having any commits yet.
>>
>> Change the output of "status" to say "No commits yet" when "git
>> status" is run on a fresh repo (or orphan branch), while retaining
>> the
>> current "Initial commit" message displayed in the template that's
>> displayed in the editor when the initial commit is being authored.
>>
>> A few alternatives considered were,
>>
>> * Waiting for initial commit
>> * Your current branch does not have any commits
>> * Current branch waiting for initial commit
>>
>> The most succint one among the alternatives was chosen.
>>
>> Helped-by: Junio C Hamano <gitster@pobox.com>
>> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>>
>> The 'FINAL' part in the subject is just my opinion about
>> this patch
>>
> Just for the note, the tests passed locally and all travis-ci builds
> jobs succeeded except for the one in which the 'GITTEXT_POISON'
> environment variable is enabled. I guess that isn't an issue, from what
> I came to know while digging about it.

No, this is a bug in your patch, the test suite should pass under
poison.

The issue is that you changed the test code I gave you (to also add more
tests, yay) along the way to do:

    test_must_fail test_i18ngrep ...

Instead of the correct form:

    test_i18ngrep ! ...

This fixup for your patch makes it work again:
    
    diff --git a/t/t7508-status.sh b/t/t7508-status.sh
    index e0d2c9e581..b3743ff0a8 100755
    --- a/t/t7508-status.sh
    +++ b/t/t7508-status.sh
    @@ -1618,7 +1618,7 @@ test_expect_success '"No commits yet" should not be noted in status output' '
            git checkout --orphan empty-branch-2 &&
            test_commit test-commit-1 &&
            git status >output &&
    -       test_must_fail test_i18ngrep "No commits yet" output
    +       test_i18ngrep ! "No commits yet" output
     '
     
     test_expect_success '"Initial commit" should be noted in commit template' '
    @@ -1635,7 +1635,7 @@ test_expect_success '"Initial commit" should not be noted in commit template' '
            touch to_be_committed_2 &&
            git add to_be_committed_2 &&
            git commit --dry-run >output &&
    -       test_must_fail test_i18ngrep "Initial commit" output
    +       test_i18ngrep ! "Initial commit" output
     '
     
     test_done

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

[Kaartic Sivaraam]

On Wed, 2017-06-21 at 16:52 +0200, Ævar Arnfjörð Bjarmason wrote:
> No, this is a bug in your patch, the test suite should pass under
> poison.
> 
> The issue is that you changed the test code I gave you (to also add
> more
> tests, yay) along the way to do:
> 
>     test_must_fail test_i18ngrep ...
> 
> Instead of the correct form:
> 
>     test_i18ngrep ! ...
> 
Yeah, I did it after reading info about 'test_must_fail' in 't/README'.
I thought it should be used for tests that fail which seemed to be a
misinterpretation. Thanks for pointing it out. Fixed it!

-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

[PATCH/FINAL] status: contextually notify user about an initial commit

[Kaartic Sivaraam]

The existing message, "Initial commit", makes sense for the commit template
notifying users that it's their initial commit, but is confusing when
merely checking the status of a fresh repository (or orphan branch)
without having any commits yet.

Change the output of "status" to say "No commits yet" when "git
status" is run on a fresh repo (or orphan branch), while retaining the
current "Initial commit" message displayed in the template that's
displayed in the editor when the initial commit is being authored.

Correspondingly change the output of "short status" to "No commits yet
on " when "git status -sb" is run on a fresh repo (or orphan branch).

A few alternatives considered were,

 * Waiting for initial commit
 * Your current branch does not have any commits
 * Current branch waiting for initial commit

The most succint one among the alternatives was chosen.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 Change(s): 
 * Added the corresponding change to short status that was
   missing in the previous patch.
 * Fixed broken tests


 Note: This is my last attempt to try sending patches using my
 email client in case this one is also line wrapped, please let
 me so that I could avoid sending through my email-client altogether.

 I'm trying this because I forgot to turn off line wrapping in my 
 email-client while sending previous patches. Hope it works!

 builtin/commit.c  |  1 +
 t/t7501-commit.sh |  2 +-
 t/t7508-status.sh | 30 ++++++++++++++++++++++++++++++
 wt-status.c       |  7 +++++--
 wt-status.h       |  1 +
 5 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 8d1cac062..3d614a2ac 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1648,6 +1648,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 		usage_with_options(builtin_commit_usage, builtin_commit_options);
 
 	status_init_config(&s, git_commit_config);
+	s.commit_template = 1;
 	status_format = STATUS_FORMAT_NONE; /* Ignore status.short */
 	s.colopts = 0;
 
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 0b6da7ae1..fa61b1a4e 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -18,7 +18,7 @@ test_expect_success 'initial status' '
 	echo bongo bongo >file &&
 	git add file &&
 	git status >actual &&
-	test_i18ngrep "Initial commit" actual
+	test_i18ngrep "No commits yet" actual
 '
 
 test_expect_success 'fail initial amend' '
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 5edcc6edf..db709048c 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -1499,4 +1499,34 @@ test_expect_success 'git commit -m will commit a staged but ignored submodule' '
 	git config -f .gitmodules  --remove-section submodule.subname
 '
 
+test_expect_success '"No commits yet" should be noted in status output' '
+	git checkout --orphan empty-branch-1 &&
+	git status >output &&
+	test_i18ngrep "No commits yet" output
+'
+
+test_expect_success '"No commits yet" should not be noted in status output' '
+	git checkout --orphan empty-branch-2 &&
+	test_commit test-commit-1 &&
+	git status >output &&
+	test_i18ngrep ! "No commits yet" output
+'
+
+test_expect_success '"Initial commit" should be noted in commit template' '
+	git checkout --orphan empty-branch-3 &&
+	touch to_be_committed_1 &&
+	git add to_be_committed_1 &&
+	git commit --dry-run >output &&
+	test_i18ngrep "Initial commit" output
+'
+
+test_expect_success '"Initial commit" should not be noted in commit template' '
+	git checkout --orphan empty-branch-4 &&
+	test_commit test-commit-2 &&
+	touch to_be_committed_2 &&
+	git add to_be_committed_2 &&
+	git commit --dry-run >output &&
+	test_i18ngrep ! "Initial commit" output
+'
+
 test_done
diff --git a/wt-status.c b/wt-status.c
index 068de38b5..c711ef86e 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1578,7 +1578,10 @@ static void wt_longstatus_print(struct wt_status *s)
 
 	if (s->is_initial) {
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
-		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
+		status_printf_ln(s, color(WT_STATUS_HEADER, s),
+				 s->commit_template
+				 ? _("Initial commit")
+				 : _("No commits yet"));
 		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
 	}
 
@@ -1748,7 +1751,7 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)
 #define LABEL(string) (s->no_gettext ? (string) : _(string))
 
 	if (s->is_initial)
-		color_fprintf(s->fp, header_color, LABEL(N_("Initial commit on ")));
+		color_fprintf(s->fp, header_color, LABEL(N_("No commits yet on ")));
 
 	if (!strcmp(s->branch, "HEAD")) {
 		color_fprintf(s->fp, color(WT_STATUS_NOBRANCH, s), "%s",
diff --git a/wt-status.h b/wt-status.h
index 8a3864783..2389f0839 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -76,6 +76,7 @@ struct wt_status {
 	char color_palette[WT_STATUS_MAXSLOT][COLOR_MAXLEN];
 	unsigned colopts;
 	int null_termination;
+	int commit_template;
 	int show_branch;
 	int hints;
 
-- 
2.11.0

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

[Junio C Hamano]

Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:

> On Wed, 2017-06-21 at 16:52 +0200, Ævar Arnfjörð Bjarmason wrote:
>> No, this is a bug in your patch, the test suite should pass under
>> poison.
>> 
>> The issue is that you changed the test code I gave you (to also add
>> more
>> tests, yay) along the way to do:
>> 
>>     test_must_fail test_i18ngrep ...
>> 
>> Instead of the correct form:
>> 
>>     test_i18ngrep ! ...
>> 
> Yeah, I did it after reading info about 'test_must_fail' in 't/README'.
> I thought it should be used for tests that fail which seemed to be a
> misinterpretation. Thanks for pointing it out. Fixed it!

Actually, test_must_fail _is_ to be used to expect that the command
being tested to fail.  The issue is with i18ngrep, where it is
rendered to a glorified "true" under the poison build.  By writing 

    test_must_fail test_i18ngrep ...

you are saying that you expect test_i18ngrep to fail, but the point
of i18ngrep is not to fail under the poison build, so...

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

[Junio C Hamano]

Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:

> The existing message, "Initial commit", makes sense for the commit template
> notifying users that it's their initial commit, but is confusing when
> merely checking the status of a fresh repository (or orphan branch)
> without having any commits yet.
>
> Change the output of "status" to say "No commits yet" when "git
> status" is run on a fresh repo (or orphan branch), while retaining the
> current "Initial commit" message displayed in the template that's
> displayed in the editor when the initial commit is being authored.
>
> Correspondingly change the output of "short status" to "No commits yet
> on " when "git status -sb" is run on a fresh repo (or orphan branch).
>
> A few alternatives considered were,
>
>  * Waiting for initial commit
>  * Your current branch does not have any commits
>  * Current branch waiting for initial commit
>
> The most succint one among the alternatives was chosen.
>
> Helped-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
>  Change(s): 
>  * Added the corresponding change to short status that was
>    missing in the previous patch.
>  * Fixed broken tests
>
>
>  Note: This is my last attempt to try sending patches using my
>  email client in case this one is also line wrapped, please let
>  me so that I could avoid sending through my email-client altogether.
>
>  I'm trying this because I forgot to turn off line wrapping in my 
>  email-client while sending previous patches. Hope it works!

You can check by downloading what you sent out (I showed you how in
the other thread).

It seems that there are funny non-breaking spaces in the additional
text below "---" but before the diffstat, but they are not part of
patch text anyway.

You seem to havespelled "Ævar" differently (perhaps difference
between NFD vs NFC ???) which seems to confuse mailinfo, but I don't
have time to dig into it myself (it is quicker for me to edit your
Signed-off-by: while queuing).

Ah, wait... it's not like Ævar is relaying your work; it's more like
some code / tests were given by him to you to incorporate into this,
so I suspect that two S-o-b: from you two should be in the reverse
order.  I'll swap them while queuing.

Thanks.

Re: [PATCH/FINAL] status: contextually notify user about an initial commit

[Kaartic Sivaraam]

On Wed, 2017-06-21 at 19:10 -0700, Junio C Hamano wrote:
> You can check by downloading what you sent out (I showed you how in
> the other thread).
> 
> It seems that there are funny non-breaking spaces in the additional
> text below "---" but before the diffstat, but they are not part of
> patch text anyway.
> 
> You seem to havespelled "Ævar" differently (perhaps difference
> between NFD vs NFC ???) which seems to confuse mailinfo, but I don't
> have time to dig into it myself (it is quicker for me to edit your
> Signed-off-by: while queuing).
> 
> Ah, wait... it's not like Ævar is relaying your work; it's more like
> some code / tests were given by him to you to incorporate into this,
> so I suspect that two S-o-b: from you two should be in the reverse
> order.  I'll swap them while queuing.
> 
> Thanks.
So, from this I conclude the following,

"Never user e-mail clients to send patches. They seem to be bringing in
all sorts of surprising changes."

This is just a consequence of not following the advice in
Documentation/SubmittingPatches. This won't repeat in future. 
(expecting, I could hold to that statement :))

-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>