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$(echo .)org \
--cc=cworth@cworth$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=jaffe.eric@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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