git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).