From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: jc/shortstatus (was: What's cooking in git.git (Aug 2009, #02; Wed, 12))
Date: Sat, 15 Aug 2009 03:09:04 -0400 [thread overview]
Message-ID: <20090815070904.GA23389@coredump.intra.peff.net> (raw)
In-Reply-To: <7vtz0co3xe.fsf@alter.siamese.dyndns.org>
On Wed, Aug 12, 2009 at 07:14:53PM -0700, Junio C Hamano wrote:
> * jc/shortstatus (Tue Aug 4 23:55:22 2009 -0700) 12 commits
> - git stat -s: short status output
> - git stat: pathspec limits, unlike traditional "git status"
> - git stat: the beginning
> + wt-status: collect untracked files in a separate "collect" phase
> + Make git_status_config() file scope static to builtin-commit.c
> + wt-status: move wt_status_colors[] into wt_status structure
> + wt-status: move many global settings to wt_status structure
> + commit: --dry-run
> + status: show worktree status of conflicted paths separately
> + wt-status.c: rework the way changes to the index and work tree are
> summarized
> + diff-index: keep the original index intact
> + diff-index: report unmerged new entries
>
> Slowly progressing. I've addressed issues pointed out by Jeff in his
> review, and hopefully the whole thing would be ready to go.
I briefly looked over what's in next, and the fixes you made look good
to me. I've been running with this series for a little while, and I was
very pleased when "git status" showed me a more detailed description of
some unmerged paths the other day. :)
For the "git stat" portion still in pu, I have a few comments/questions:
1. Is "stat" a good name? I worry a little that it is _too_ similar to
"status", and that will cause confusion while they both exist. So
something like "git overview" would cause less confusion, and even
though it sucks to type, it will eventually replace "status" (and
in the meantime people can make aliases or whatever).
2. Does it really belong in builtin-commit.c anymore? It seems like
historical accident that "status" is so closely tied to commit. The
whole point of the new command is to _not_ be tied; I think of the
new command more as an extension of 'diff'. Admittedly, users don't
care where the source is located, but it helps the developers
understand the relationships between code.
3. Can you squash in the gitignore patch below? :)
---
diff --git a/.gitignore b/.gitignore
index c446290..14e0f51 100644
--- a/.gitignore
+++ b/.gitignore
@@ -128,6 +128,7 @@ git-show-index
git-show-ref
git-stage
git-stash
+git-stat
git-status
git-stripspace
git-submodule
next prev parent reply other threads:[~2009-08-15 7:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-13 2:14 What's cooking in git.git (Aug 2009, #02; Wed, 12) Junio C Hamano
2009-08-14 22:27 ` Jakub Narebski
2009-08-15 1:51 ` Junio C Hamano
2009-08-15 7:09 ` Jeff King [this message]
2009-08-15 8:18 ` jc/shortstatus Junio C Hamano
2009-08-15 8:45 ` jc/shortstatus Jeff King
2009-08-15 21:23 ` jc/shortstatus Junio C Hamano
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=20090815070904.GA23389@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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