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 Currently, git-status makes this distinction only in the header lines for the separate chunks of its output. But, when there are a lot of files involved, and things start scrolling, it's sometimes "hard" to associate the right header with the file of interest. So, what I've wanted from git-status is a complete encoding of the file's state on the same line as the output of the filename. Maybe something that uses two characters per file would work well. But I don't have a concrete suggestion for that---I don't think I've even successfully enumerated all possible file states with git yet... -Carl PS. If we do tighten up the output of git-status, I'd also vote for making the per-chunk headers use only 1 line each instead of 2, and also eliminating the second blank line separating each chunk.
Attachment:
pgpk25ZBTmn0y.pgp
Description: PGP signature