git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
Date
Jun 15, 2017, 08:19 UTC
Message-ID
<1497514760.2394.6.camel@gmail.com>
In-Reply-To
<20170612213759.f2scl3r46vboolna@sigill.intra.peff.net>
On Mon, 2017-06-12 at 17:37 -0400, Jeff King wrote:
Show 55 quoted lines
> 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;
Previous: Jeff KingNext: Jeff King
Message 13 of 48 in “wt-status.c: Modified status message shown for a parent-less branch”
  1. wt-status.c: Modified status message shown for a parent-less branchKaartic Sivaraam, Jun 10, 2017
  2. Kaartic SivaraamJun 10, 2017
  3. Junio C HamanoJun 10, 2017
  4. Kaartic SivaraamJun 10, 2017
  5. Kaartic SivaraamJun 10, 2017
  6. Jeff KingJun 10, 2017
  7. Junio C HamanoJun 10, 2017
  8. Kaartic SivaraamJun 12, 2017
  9. Junio C HamanoJun 12, 2017
  10. Jeff KingJun 12, 2017
  11. Junio C HamanoJun 12, 2017
  12. Jeff KingJun 12, 2017
  13. Kaartic SivaraamJun 15, 2017
  14. Jeff KingJun 15, 2017
  15. Samuel LijinJun 15, 2017
  16. Jeff KingJun 15, 2017
  17. Kaartic SivaraamJun 16, 2017
  18. Jeff KingJun 16, 2017
  19. Kaartic SivaraamJun 18, 2017
  20. Contextually notify user about an initial commitKaartic Sivaraam, Jun 18, 2017
  21. Ævar Arnfjörð BjarmasonJun 18, 2017
  22. 1/2 Contextually notify user about an initial commitKaartic Sivaraam, Jun 19, 2017
  23. 2/2 Add test for the new status messageKaartic Sivaraam, Jun 19, 2017
  24. Junio C HamanoJun 19, 2017
  25. Kaartic SivaraamJun 19, 2017
  26. Jeff KingJun 19, 2017
  27. Kaartic SivaraamJun 19, 2017
  28. Junio C HamanoJun 19, 2017
  29. 2/2 Add test for the new status messageKaartic Sivaraam, Jun 19, 2017
  30. Jeff KingJun 19, 2017
  31. Kaartic SivaraamJun 19, 2017
  32. Junio C HamanoJun 19, 2017
  33. 1/3 Contextually notify user about an initial commitKaartic Sivaraam, Jun 20, 2017
  34. 2/3 Update test(s) that used old status messageKaartic Sivaraam, Jun 20, 2017
  35. 3/3 Add tests for the contextual initial status messageKaartic Sivaraam, Jun 20, 2017
  36. Ævar Arnfjörð BjarmasonJun 20, 2017
  37. Kaartic SivaraamJun 20, 2017
  38. Ævar Arnfjörð BjarmasonJun 20, 2017
  39. Kaartic SivaraamJun 21, 2017
  40. status: contextually notify user about an initial commitKaartic Sivaraam, Jun 21, 2017
  41. Kaartic SivaraamJun 21, 2017
  42. Ævar Arnfjörð BjarmasonJun 21, 2017
  43. Kaartic SivaraamJun 21, 2017
  44. Junio C HamanoJun 21, 2017
  45. status: contextually notify user about an initial commitKaartic Sivaraam, Jun 21, 2017
  46. Junio C HamanoJun 22, 2017
  47. Kaartic SivaraamJun 22, 2017
  48. Philip OakleyJun 10, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.