"Eric Jaffe" <jaffe.eric@xxxxxxxxx> writes:
> 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
>
> instead of
> # new file: a/newfile.c
> # modified: a/oldfile.c
Why do people think mysterious single letter abbreviation is
better than spelled out words in an output meant for human
consumption?
The tag letters you get from "ls-files -t" are inconsistent with
what you would get from all the other git tools for historical
reasons, so if you want to do a single-letter abbreviation, you
first need to come up with a set of letters and translate the
output from ls-files -t into that.
Although I personally like Carl's suggestion a lot, I am still
ambivalent about it a bit.
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.
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).
I think it is a valid view for people who know how internally
git barebone porcelain works using git lowlevel, and to them
(including me), the above is more concise and appear useful.
But I am not sure if it is appropriate for "git status", which
is the tool for commit-preview. The index "git status" is
showing is the index you would get if you were to run "git
commit" with the same set of parameters, exactly for that reason
(e.g. "git status -a -v" would see "unmodified" for all tracked
paths in index->files column in the above output).
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html