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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.