Re: `git stash pop` UX Problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:

> Holger Hellmuth <hellmuth@xxxxxxxxxx> writes:
>
>> Am 24.02.2014 17:21, schrieb Matthieu Moy:
>>> $ git add foo.txt
>>> $ git status
>>> On branch master
>>> Changes to be committed:
>>>    (use "git reset HEAD <file>..." to unstage)
>>>
>>>          modified:   foo.txt
>>
>> Maybe status should display a stash count if that count is > 0, as
>> this is part of the state of the repo.
>
> Maybe it would help some users, but not me for example. My main use of
> "git stash" is a safe replacement for "git reset --hard": when I want to
> discard changes, but keep them safe just in case.
>
> So, my stash count is almost always >0, and I don't want to hear about
> it.

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

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,
and the way to do so is not limited to "stash pop" (i.e. you can
"git cherry-pick --no-commit $a_commit", or "edit" any file in the
working tree for that matter, with the same ease).

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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]