Mahmoud Al-Qudsi <mqudsi@xxxxxxxxxxxx> writes:
> I hope it is not considered too forward of me for my first post to this list
> to be a suggestion on a change to git’s behavior (though not in any
> functional manner); but a persistent frustration for me and everyone I’ve
> worked with (so, yes, 100% based off of anecdata) has been that the output
> of `git status` does not include the commit or commit-ish, and one must
> resort to a `git rev-parse HEAD` call.
HEAD is, unless you are about to create a root commit, always a
commit and not other kind of commit-ish, so there is no need to say
"or commit-ish" here.
If this were a proposal to add human-readable information about the
current commit (e.g. the title of the commit), perhaps next to "On
branch my-topic" line, e.g.
$ git status
On branch my-topic
HEAD is at "*.[ch] refactoring: make use of the FREE_AND_NULL() macro"
Changes to be committed:
...
I can understand why sometimes such a piece of information may be
useful to users. But I am puzzled by your `git rev-parse HEAD`.
Suppose you get frustrated due to lack of HEAD information in the
output from 'git status':
$ git status
On branch my-topic
Changes to be committed:
...
$ git rev-parse HEAD
and that was the reason why you resorted to "git rev-parse HEAD"
immediately after asking "git status" about the current state.
That command may say
$ git rev-parse HEAD
88ce3ef636b1385e861ec0e9e2155248b999b032
or it may say
$ git rev-parse HEAD
e140f7afddcdce2bae062ea1578eac38c744e3a5
What would you do differently, after seeing this random-looking
40-character string, based on what it is? Do you know recent commit
object names by heart and can tell, immediately when you see 88ce3...,
"ah, that was me fixing foo", as opposed to e140f7a... that is a
different change you can immediately identify?
