{"thread":{"id":"46197","subject":"[suggestion] Include commit-ish in git status output","startedAt":"2017-06-15T23:44:12Z","lastAt":"2017-08-07T22:53:21Z","messageCount":6,"participants":["Mahmoud Al-Qudsi","Samuel Lijin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"322424","messageId":"CACcTrKfPKdPCVONMcGRbisK_WOt70yLdjavZnLTMMVocrwzk1w@mail.gmail.com","threadId":"46197","inReplyTo":null,"subject":"[suggestion] Include commit-ish in git status output","fromName":"Mahmoud Al-Qudsi","fromEmail":"mqudsi@neosmart.net","sentAt":"2017-06-15T23:43:46Z","receivedAt":"2017-06-15T23:44:12Z","isPatch":false,"sender":{"key":"mqudsi@neosmart.net","avatar":"https://gravatar.com/avatar/c2643dd7c6df61aed49d9f3d917ac6d61cafbbda5f9b1619f50d3b749dca415a?d=mp&s=160"},"body":"Hello all,\n\nI hope it is not considered too forward of me for my first post to this list\nto be a suggestion on a change to git’s behavior (though not in any\nfunctional manner); but a persistent frustration for me and everyone I’ve\nworked with (so, yes, 100% based off of anecdata) has been that the output\nof `git status` does not include the commit or commit-ish, and one must\nresort to a `git rev-parse HEAD` call.\n\nI apologize unreservedly if this matter has already been discussed and put to\nrest; I attempted to search the archives for a reference to this suggestion but\nwas not met with any matches.\n\nAdditionally, if this list is not the right place to make such a suggestion,\nthen I would appreciate if someone could kindly point me in the correct\ndirection and apologize for littering.\n\nThank you kindly,\n\nMahmoud Al-Qudsi\nNeoSmart Technologies\n"},{"id":"322425","messageId":"CAJZjrdW=1MbT=Lmouswez3W4hGP=anuMqMnQPkLta_fhUU4hCg@mail.gmail.com","threadId":"46197","inReplyTo":"CACcTrKfPKdPCVONMcGRbisK_WOt70yLdjavZnLTMMVocrwzk1w@mail.gmail.com","subject":"Re: [suggestion] Include commit-ish in git status output","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-06-15T23:55:20Z","receivedAt":"2017-06-15T23:56:07Z","isPatch":false,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":"On Thu, Jun 15, 2017 at 7:43 PM, Mahmoud Al-Qudsi <mqudsi@neosmart.net> wrote:\n> Hello all,\n>\n> I hope it is not considered too forward of me for my first post to this list\n> to be a suggestion on a change to git’s behavior (though not in any\n> functional manner); but a persistent frustration for me and everyone I’ve\n> worked with (so, yes, 100% based off of anecdata) has been that the output\n> of `git status` does not include the commit or commit-ish, and one must\n> resort to a `git rev-parse HEAD` call.\n\nCan you elaborate on why you consider this useful specifically?\n\nDo you think adding a $(git rev-parse HEAD) to your PS1 would do the trick?\n\n> I apologize unreservedly if this matter has already been discussed and put to\n> rest; I attempted to search the archives for a reference to this suggestion but\n> was not met with any matches.\n>\n> Additionally, if this list is not the right place to make such a suggestion,\n> then I would appreciate if someone could kindly point me in the correct\n> direction and apologize for littering.\n\nNo worries, you're in the right place.\n\n> Thank you kindly,\n>\n> Mahmoud Al-Qudsi\n> NeoSmart Technologies\n"},{"id":"322426","messageId":"CACcTrKdatvtqoMDiR5DR6cP_0gsqZnQDGbpq6vj6MU-+ABWF_w@mail.gmail.com","threadId":"46197","inReplyTo":"CAJZjrdW=1MbT=Lmouswez3W4hGP=anuMqMnQPkLta_fhUU4hCg@mail.gmail.com","subject":"Re: [suggestion] Include commit-ish in git status output","fromName":"Mahmoud Al-Qudsi","fromEmail":"mqudsi@neosmart.net","sentAt":"2017-06-16T00:10:13Z","receivedAt":"2017-06-16T00:10:39Z","isPatch":false,"sender":{"key":"mqudsi@neosmart.net","avatar":"https://gravatar.com/avatar/c2643dd7c6df61aed49d9f3d917ac6d61cafbbda5f9b1619f50d3b749dca415a?d=mp&s=160"},"body":"On Thu, Jun 15, 2017 at 6:55 PM, Samuel Lijin <sxlijin@gmail.com> wrote:\n>\n> Can you elaborate on why you consider this useful specifically?\n\nPersonally, primary usages of the current commit-ish info are to file bug\nreports that include the specific git revision of any given branch that a bug\nwas observed in/on and to quickly note the currently checked-out revision prior\nto pulling the latest changes from an upstream server so that I can rollback\nwithout needing to tag/branch if needed.\n\nBut that's not really the reason why I emailed in with this suggestion. I think\nsemantically the \"status\" of a working folder is perhaps best summed up as the\nsha1 of the commit (or its commit-ish, for short) plus the currently\nstaged/unstaged changes to the checked out copy of that revision to indicate\nthe _current_ status (there's that word again!) of the current git directory,\ncombined with branch information to indicate where any staged changes would be\ncommitted to.\n\nCurrently, git shows two-thirds of the information needed to actually describe\nthe actual working state (status) of a git directory (being the branch and\nstaged/unchanged changes to HEAD), but does not describe what HEAD is in a\nstateless manner.\n\n>\n> Do you think adding a $(git rev-parse HEAD) to your PS1 would do the trick?\n\nThis is a bit more subjective, but my personal preference is to keep a minimal\nshell that retains its behavior regardless of whether I'm cd'd into a git repo\nor if I'm transcoding my music collection.\n\nI have no problem needing to execute something to view the commit-ish when it\nis desired; this suggestion is merely focusing on what the something should be.\nI have no problem using `git rev-parse` for other tasks, but feel that needing\na combination of `git status` and `git rev-parse HEAD` to accurately get a\nsummary of the current state of a repo is perhaps much.\n\n\nThanks.\n"},{"id":"322493","messageId":"xmqqefujwqz0.fsf@gitster.mtv.corp.google.com","threadId":"46197","inReplyTo":"CACcTrKfPKdPCVONMcGRbisK_WOt70yLdjavZnLTMMVocrwzk1w@mail.gmail.com","subject":"Re: [suggestion] Include commit-ish in git status output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-16T21:41:07Z","receivedAt":"2017-06-16T21:41:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mahmoud Al-Qudsi <mqudsi@neosmart.net> writes:\n\n> I hope it is not considered too forward of me for my first post to this list\n> to be a suggestion on a change to git’s behavior (though not in any\n> functional manner); but a persistent frustration for me and everyone I’ve\n> worked with (so, yes, 100% based off of anecdata) has been that the output\n> of `git status` does not include the commit or commit-ish, and one must\n> resort to a `git rev-parse HEAD` call.\n\nHEAD is, unless you are about to create a root commit, always a\ncommit and not other kind of commit-ish, so there is no need to say\n\"or commit-ish\" here.\n\nIf this were a proposal to add human-readable information about the\ncurrent commit (e.g. the title of the commit), perhaps next to \"On\nbranch my-topic\" line, e.g.\n\n    $ git status\n    On branch my-topic\n    HEAD is at \"*.[ch] refactoring: make use of the FREE_AND_NULL() macro\"\n    Changes to be committed:\n       ...\n\nI can understand why sometimes such a piece of information may be\nuseful to users.  But I am puzzled by your `git rev-parse HEAD`.\n\nSuppose you get frustrated due to lack of HEAD information in the\noutput from 'git status':\n\n    $ git status\n    On branch my-topic\n    Changes to be committed:\n\t...\n    $ git rev-parse HEAD\n\nand that was the reason why you resorted to \"git rev-parse HEAD\"\nimmediately after asking \"git status\" about the current state.\n\nThat command may say\n\n    $ git rev-parse HEAD\n    88ce3ef636b1385e861ec0e9e2155248b999b032\n\nor it may say\n\n    $ git rev-parse HEAD\n    e140f7afddcdce2bae062ea1578eac38c744e3a5\n\nWhat would you do differently, after seeing this random-looking\n40-character string, based on what it is?  Do you know recent commit\nobject names by heart and can tell, immediately when you see 88ce3...,\n\"ah, that was me fixing foo\", as opposed to e140f7a... that is a\ndifferent change you can immediately identify?\n"},{"id":"325764","messageId":"CACcTrKewZRZpHotZ8GpO9zFifTdjkzP2th=KqkQqTvJb_k3W9w@mail.gmail.com","threadId":"46197","inReplyTo":"xmqqefujwqz0.fsf@gitster.mtv.corp.google.com","subject":"Re: [suggestion] Include commit-ish in git status output","fromName":"Mahmoud Al-Qudsi","fromEmail":"mqudsi@neosmart.net","sentAt":"2017-08-07T21:41:18Z","receivedAt":"2017-08-07T21:41:47Z","isPatch":false,"sender":{"key":"mqudsi@neosmart.net","avatar":"https://gravatar.com/avatar/c2643dd7c6df61aed49d9f3d917ac6d61cafbbda5f9b1619f50d3b749dca415a?d=mp&s=160"},"body":"On Fri, Jun 16, 2017 at 4:41 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> HEAD is, unless you are about to create a root commit, always a\n> commit and not other kind of commit-ish, so there is no need to say\n> \"or commit-ish\" here.\n\nI apologize for my errant terminology, I thought commitish was what\nthe abbreviated\nSHA1 was called. My proposal was to show either the full SHA1 or the abbreviated\nSHA1 in the output of `git status`.\n\n> What would you do differently, after seeing this random-looking\n> 40-character string, based on what it is?  Do you know recent commit\n> object names by heart and can tell, immediately when you see 88ce3...,\n> \"ah, that was me fixing foo\", as opposed to e140f7a... that is a\n> different change you can immediately identify?\n\nI obviously do not know recent commits by heart - the aim is to be\nable to easily\ncopy & paste or visually compare against another value.\n\nAside from the practical implications of having the commit SHA\nincluded in the output\nof `git status`, I have also pointed out my ideological reasons for\nit. `git status` currently\nprints an incomplete picture of the local repository state, and\nwithout an indication of\n_which_ commit HEAD currently is, the remainder of the content\n\"expires\" and is of no\nuse at some later date.\n\nLooking back, I probably should have started with that. `git status`\ngives the status of the\n_relative_ current state of the local repository without printing any\ninformation that can be\nused as an _absolute_ reference to \"frame\" the results of the `git\nstatus` command. The\nrelative state of a repository is useless for any sort of machine or\nhuman analysis, since it\nwould require the state of both the cached remote and local indices to\nbe identical to be of\nany use.\n\nIf I run `git status`, make, commit, and push some changes, then run\n`git status` once more,\nthe output of the command can be identical to the previous run, _even\nthough the actual\nstate of the repo has changed_ which is... less than useful and\npotentially misleading.\n\nYes, anyone familiar with git knows that the output of `git status` is\nonly showing you a summary\nof the diff of the working tree vs HEAD. My argument is that all it\nwould take is another 8 characters\nappending to the \"On branch xxxx\" line to make it an infinitely more\nuseful command.\n\nThank you,\n\nMahmoud Al-Qudsi\nNeoSmart Technologies\n"},{"id":"325773","messageId":"xmqq4ltjng6m.fsf@gitster.mtv.corp.google.com","threadId":"46197","inReplyTo":"CACcTrKewZRZpHotZ8GpO9zFifTdjkzP2th=KqkQqTvJb_k3W9w@mail.gmail.com","subject":"Re: [suggestion] Include commit-ish in git status output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-07T22:53:05Z","receivedAt":"2017-08-07T22:53:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mahmoud Al-Qudsi <mqudsi@neosmart.net> writes:\n\n> Looking back, I probably should have started with that. `git\n> status` gives the status of the _relative_ current state of the\n> local repository without printing any information that can be used\n> as an _absolute_ reference to \"frame\" the results of the `git\n> status` command.\n\nYeah, that may be a good characterization of what 'git status'\ndoes.  Another thing is that it gives only a summary.  It may say\n\"this and that path were changed\", but it does not exactly say \"how\"\nthey were changed.  So from that point of view, even if you know\nwhich absolute reference the status of the working tree and the\nindex being reported is relative to, it still does not give you\nmuch for you to be able to reproduce the exact state.  That is not\nthe purpose of the tool---it is to help the user who is aware of\nwhere s/he started from.\n\n> If I run `git status`, make, commit, and push some changes, then\n> run `git status` once more, the output of the command can be\n> identical to the previous run, _even though the actual state of\n> the repo has changed_ which is... less than useful and potentially\n> misleading.\n\nI do not quite understand why it is misleading.\n"}]}