On Thu, Jun 15, 2017 at 6:55 PM, Samuel Lijin <sxli...@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.
