From: Andreas Ericsson <ae@op5.se>
To: Junio C Hamano <junkio@cox.net>
Cc: Eric Jaffe <jaffe.eric@gmail.com>, Carl Worth <cworth@cworth.org>,
git@vger.kernel.org
Subject: Re: git-status too verbose?
Date: Tue, 07 Mar 2006 11:22:55 +0100 [thread overview]
Message-ID: <440D5EFF.6050300@op5.se> (raw)
In-Reply-To: <7v3bhumvt6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>>I agree that it would be useful if we had a tool that showed the
>>>two status that matter for each file, grouped together on one
>>>line, e.g.
>>> HEAD->index index->files
>>> ------------------------------------------------
>>> hello.c unmodified modified
>>> world.c modified unmodified
>>> frotz.c new unmodified
>>> ...
>>> garbage.c~ ??? n/a
>>>for the current index file and the current HEAD commit.
>>
>>Could we have 'same' or some such instead of 'unmodified'? It's a bit
>>close to 'modified' for the eye to find it quickly.
>>
>>
>>>You obviously need to learn how to read it though. The first
>>>column means what you _would_ commit if you just said "git
>>>commit" without doing anything else now; the second column is
>>>what you _could_ commit if you did some update-index and then
>>>said "git commit" (or ran "git commit" with paths arguments).
>>
>>Pretty-printing will be easier if the filename is last, and it will
>>look a lot neater if all columns are aligned.
>
>
> Somebody who feels strongly about this can propose a design.
> Although I am not particularly fond of the current output, I am
> not volunteering ;-).
>
> It would be nicer if the proposal was accompanied by a patch,
> but that is not a requirement for discussion.
>
I'll see if I can get around to it tonight.
> The points that design would address should include:
>
> - what to do _if_ we choose to do rename detection? you need
> two pathnames.
I like the gitk view of these things, "renamed from" and "renamed to",
although we'll likely want shorter names since the filename part can't
start before column max_label_name * 2 + 4 if we assume two spaces
minimum between word-columns. Perhaps mv-to and mv-from?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2006-03-07 10:23 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
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 [this message]
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=440D5EFF.6050300@op5.se \
--to=ae@op5.se \
--cc=cworth@cworth.org \
--cc=git@vger.kernel.org \
--cc=jaffe.eric@gmail.com \
--cc=junkio@cox.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).