Re: `git stash pop` UX Problem

From: Stephen Leake <stephen_leake@stephe-leake.org>
Date: Feb 25, 2014, 20:48 UTC
Message-ID: <85r46q537a.fsf@stephe-leake.org>
In-Reply-To: <xmqqwqgj57n9.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@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".

-- 
-- Stephe