[suggestion] Include commit-ish in git status output

[suggestion] Include commit-ish in git status output

[Mahmoud Al-Qudsi]

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

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

[Samuel Lijin]

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

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?

> 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.

No worries, you're in the right place.

> Thank you kindly,
>
> Mahmoud Al-Qudsi
> NeoSmart Technologies

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

[Mahmoud Al-Qudsi]

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.

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

[Junio C Hamano]

Mahmoud Al-Qudsi <mqudsi@neosmart.net> 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?

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

[Mahmoud Al-Qudsi]

On Fri, Jun 16, 2017 at 4:41 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.

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`.

> 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?

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

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

[Junio C Hamano]

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

> 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.

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.

> 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.

I do not quite understand why it is misleading.