[suggestion] Include commit-ish in git status output

Hello all,

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.

I apologize unreservedly if this matter has already been discussed and put to rest; I attempted to search the archives for a reference to this suggestion but was not met with any matches.

Additionally, if this list is not the right place to make such a suggestion, then I would appreciate if someone could kindly point me in the correct direction and apologize for littering.

Thank you kindly,

Mahmoud Al-Qudsi NeoSmart Technologies

On Thu, Jun 15, 2017 at 7:43 PM, Mahmoud Al-Qudsi <mqudsi@neosmart.net> wrote:

Can you elaborate on why you consider this useful specifically?

Do you think adding a $(git rev-parse HEAD) to your PS1 would do the trick?

No worries, you're in the right place.

On Thu, Jun 15, 2017 at 6:55 PM, Samuel Lijin <sxlijin@gmail.com> wrote:

Personally, primary usages of the current commit-ish info are to file bug reports that include the specific git revision of any given branch that a bug was observed in/on and to quickly note the currently checked-out revision prior to pulling the latest changes from an upstream server so that I can rollback without needing to tag/branch if needed.

But that's not really the reason why I emailed in with this suggestion. I think semantically the "status" of a working folder is perhaps best summed up as the sha1 of the commit (or its commit-ish, for short) plus the currently staged/unstaged changes to the checked out copy of that revision to indicate the _current_ status (there's that word again!) of the current git directory, combined with branch information to indicate where any staged changes would be committed to.

Currently, git shows two-thirds of the information needed to actually describe the actual working state (status) of a git directory (being the branch and staged/unchanged changes to HEAD), but does not describe what HEAD is in a stateless manner.

This is a bit more subjective, but my personal preference is to keep a minimal shell that retains its behavior regardless of whether I'm cd'd into a git repo or if I'm transcoding my music collection.

I have no problem needing to execute something to view the commit-ish when it is desired; this suggestion is merely focusing on what the something should be. I have no problem using `git rev-parse` for other tasks, but feel that needing a combination of `git status` and `git rev-parse HEAD` to accurately get a summary of the current state of a repo is perhaps much.

Thanks.

Mahmoud Al-Qudsi <mqudsi@neosmart.net> writes:

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?

On Fri, Jun 16, 2017 at 4:41 PM, Junio C Hamano <gitster@pobox.com> wrote:

I apologize for my errant terminology, I thought commitish was what the abbreviated SHA1 was called. My proposal was to show either the full SHA1 or the abbreviated SHA1 in the output of `git status`.

I obviously do not know recent commits by heart - the aim is to be able to easily copy & paste or visually compare against another value.

Aside from the practical implications of having the commit SHA included in the output of `git status`, I have also pointed out my ideological reasons for it. `git status` currently prints an incomplete picture of the local repository state, and without an indication of _which_ commit HEAD currently is, the remainder of the content "expires" and is of no use at some later date.

Looking back, I probably should have started with that. `git status` gives the status of the _relative_ current state of the local repository without printing any information that can be used as an _absolute_ reference to "frame" the results of the `git status` command. The relative state of a repository is useless for any sort of machine or human analysis, since it would require the state of both the cached remote and local indices to be identical to be of any use.

If I run `git status`, make, commit, and push some changes, then run `git status` once more, the output of the command can be identical to the previous run, _even though the actual state of the repo has changed_ which is... less than useful and potentially misleading.

Yes, anyone familiar with git knows that the output of `git status` is only showing you a summary of the diff of the working tree vs HEAD. My argument is that all it would take is another 8 characters appending to the "On branch xxxx" line to make it an infinitely more useful command.

Thank you,

Mahmoud Al-Qudsi NeoSmart Technologies

Mahmoud Al-Qudsi <mqudsi@neosmart.net> writes:

Yeah, that may be a good characterization of what 'git status' does. Another thing is that it gives only a summary. It may say "this and that path were changed", but it does not exactly say "how" they were changed. So from that point of view, even if you know which absolute reference the status of the working tree and the index being reported is relative to, it still does not give you much for you to be able to reproduce the exact state. That is not the purpose of the tool---it is to help the user who is aware of where s/he started from.

I do not quite understand why it is misleading.