Re: [suggestion] Include commit-ish in git status output

[Mahmoud Al-Qudsi <mqudsi@neosmart.net>]

On Thu, Jun 15, 2017 at 6:55 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
>
> Can you elaborate on why you consider this useful specifically?

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.

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

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.