From: Shawn Pearce <spearce@spearce.org>
To: Carl Worth <cworth@cworth.org>
Cc: Eric Jaffe <jaffe.eric@gmail.com>, git@vger.kernel.org
Subject: Re: git-status too verbose?
Date: Mon, 6 Mar 2006 12:56:14 -0500 [thread overview]
Message-ID: <20060306175614.GG27965@spearce.org> (raw)
In-Reply-To: <87irqrzcs7.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> On Sat, 4 Mar 2006 12:52:17 -0500, "Eric Jaffe" wrote:
> > I was wondering if anyone else thinks that git-status should be more
> > like "git-diff --name-status". That is,
> > # A a/newfile.c
> > # M a/oldfile.c
>
> Something like that does seem appealing.
>
> There are at least two issues with doing it:
>
> 1) It might be tricky coming up with canonical single characters to be
> used consistently within git. For example, git-ls-files currently
> does do some single-character state indication, but it can be
> rather confusing at times. For example:
>
> State Option Character
> ----- ------ ---------
> Modified -m C
> Unmerged -u M
> Cached -c H
>
> And that looks like a permanent problem. For legacy reasons,
> I don't think we can change either the options or the output
> characters of git-ls-files. But perhaps we could at least
> agree on a single, consistent mapping for all future uses.
>
> 2) In an important sense, git-status is not verbose enough. For
> example, given a single line such as the following:
>
> modified: some-file
>
> This could indicate at least two different states for some-file:
>
> 1) Modified and updated into the index
>
> 2) Modified in working tree, but not updated in the index
I've played around with this idea a little bit in pg's pg-status
command but I most likely do not have all cases covered.
In general I try to show HEAD<-->index first using uppercase letters
then index<-->working directory second in lowercase letters.
Here's the critical portion of pg-status:
git-diff-index --cached --name-status HEAD | sed -e 's/ / /'
if test $index_only = n
then
git-diff-files --name-status | sed \
-e 's/ / /' \
-e 's/^D /g /' \
-e 's/^M /m /' \
-e '/^U /d'
pg--ls-others | sed 's/^/x /'
fi
Thus far I've found it useful to behave this way and I haven't run
up against any states which didn't make immediate sense to me.
Here's the documentation I have in pg-status describing what it
can show:
Status indicators (displayed in column 1):
A : New file has been marked for addition with pg-add.
D : Existing file has been marked as deleted with pg-rm.
M : Existing file has been modified (and is known to the index).
U : File still has unmerged hunks, see pg-resolved.
m : Existing file (maybe) has been modified (use -q to know for sure).
g : File has been removed from directory but not marked with pg-rm.
x : File is not known to repository and isn't being ignored.
--
Shawn.
next prev parent reply other threads:[~2006-03-06 17:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-04 17:52 git-status too verbose? Eric Jaffe
2006-03-06 17:46 ` Carl Worth
2006-03-06 17:56 ` Shawn Pearce [this message]
2006-03-07 0:21 ` Junio C Hamano
2006-03-07 5:35 ` Joshua N Pritikin
2006-03-07 9:17 ` Karl Hasselström
2006-03-07 9:38 ` Johannes Schindelin
2006-03-07 9:19 ` Andreas Ericsson
2006-03-07 9:46 ` Junio C Hamano
2006-03-07 10:22 ` Andreas Ericsson
2006-03-07 18:22 ` Linus Torvalds
2006-03-07 18:26 ` Carl Worth
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=20060306175614.GG27965@spearce.org \
--to=spearce@spearce.org \
--cc=cworth@cworth.org \
--cc=git@vger.kernel.org \
--cc=jaffe.eric@gmail.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 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.