From: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
To: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, sandals@crustytoothpaste.net
Subject: Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch
Date: Thu, 15 Jun 2017 13:49:20 +0530 [thread overview]
Message-ID: <1497514760.2394.6.camel@gmail.com> (raw)
In-Reply-To: <20170612213759.f2scl3r46vboolna@sigill.intra.peff.net>
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;
next prev parent reply other threads:[~2017-06-15 8:19 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-10 1:52 [PATCH] wt-status.c: Modified status message shown for a parent-less branch Kaartic Sivaraam
2017-06-10 2:10 ` Kaartic Sivaraam
2017-06-10 2:23 ` Junio C Hamano
2017-06-10 8:44 ` Kaartic Sivaraam
2017-06-10 9:36 ` Kaartic Sivaraam
2017-06-10 10:21 ` Jeff King
2017-06-10 11:02 ` Junio C Hamano
2017-06-12 8:10 ` Kaartic Sivaraam
2017-06-12 18:28 ` Junio C Hamano
2017-06-12 21:20 ` Jeff King
2017-06-12 21:31 ` Junio C Hamano
2017-06-12 21:37 ` Jeff King
2017-06-15 8:19 ` Kaartic Sivaraam [this message]
2017-06-15 8:42 ` Jeff King
2017-06-15 11:43 ` Samuel Lijin
2017-06-15 13:12 ` Jeff King
2017-06-16 10:36 ` Kaartic Sivaraam
2017-06-16 10:50 ` Jeff King
2017-06-18 7:35 ` [PATCH/Almost final] " Kaartic Sivaraam
2017-06-18 7:53 ` [PATCH/ALMOST FINAL] Contextually notify user about an initial commit Kaartic Sivaraam
2017-06-18 8:34 ` Ævar Arnfjörð Bjarmason
2017-06-19 2:41 ` [PATCH 1/2] " Kaartic Sivaraam
2017-06-19 2:44 ` [PATCH 2/2] Add test for the new status message Kaartic Sivaraam
2017-06-19 4:32 ` Junio C Hamano
2017-06-19 17:59 ` Kaartic Sivaraam
2017-06-19 18:04 ` Jeff King
2017-06-19 18:33 ` Kaartic Sivaraam
2017-06-19 4:29 ` [PATCH 1/2] Contextually notify user about an initial commit Junio C Hamano
2017-06-19 2:41 ` [PATCH 2/2] Add test for the new status message Kaartic Sivaraam
2017-06-19 9:10 ` [PATCH/ALMOST FINAL] Contextually notify user about an initial commit Jeff King
2017-06-19 13:24 ` Kaartic Sivaraam
2017-06-19 15:47 ` Junio C Hamano
2017-06-20 3:02 ` [PATCH 1/3] " Kaartic Sivaraam
2017-06-20 3:02 ` [PATCH 2/3] Update test(s) that used old status message Kaartic Sivaraam
2017-06-20 3:02 ` [PATCH 3/3] Add tests for the contextual initial " Kaartic Sivaraam
2017-06-20 7:26 ` [PATCH 1/3] Contextually notify user about an initial commit Ævar Arnfjörð Bjarmason
2017-06-20 13:37 ` Kaartic Sivaraam
2017-06-20 14:41 ` Ævar Arnfjörð Bjarmason
2017-06-21 2:34 ` Kaartic Sivaraam
2017-06-21 2:37 ` [PATCH/FINAL] status: contextually " Kaartic Sivaraam
2017-06-21 14:35 ` Kaartic Sivaraam
2017-06-21 14:52 ` Ævar Arnfjörð Bjarmason
2017-06-21 17:45 ` Kaartic Sivaraam
2017-06-21 18:45 ` Junio C Hamano
2017-06-21 18:16 ` Kaartic Sivaraam
2017-06-22 2:10 ` Junio C Hamano
2017-06-22 3:01 ` Kaartic Sivaraam
2017-06-10 14:44 ` [PATCH] wt-status.c: Modified status message shown for a parent-less branch Philip Oakley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1497514760.2394.6.camel@gmail.com \
--to=kaarticsivaraam91196@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).