Junio C Hamano <gits...@pobox.com> writes:
> "status" is about reminding the user what changes are already in the
> index (i.e. what you would commit) and what changes are in the
> working tree, from which you could further update the index with
> (i.e. what you could commit).
I believe "status" should tell me everything git knows about the current
workspace in a resonably concise way. That includes the stash.
> One _could_ argue that stashed changes are what could be reflected
> to the working tree and form the source of the latter, but my gut
> feeling is that it is a rather weak argument. At that point you are
> talking about what you could potentially change in the working tree,
No, I saved things in the stash on purpose. For example, I had changes
that were not ready to commit, but I wanted to do a merge from upstream.
There are workflows where the stash is not important; provide an option
to 'git status' that means "ignore stash".
> So, I tend to agree with you, while I do understand where "I want to
> know about what is in stash" is coming from (and that is why we do
> have "git stash list" command).
My Emacs front end currently checks both 'git status' and 'git stash
list' to build "the status of the current workspace".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html