Re: [PATCH] git-stash: add flag to skip "git reset --hard"

From: Junio C Hamano <gitster@pobox.com>
Date: May 2, 2016, 22:44 UTC
Message-ID: <xmqqbn4oqdv8.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <5727BE65.3040004@google.com>

Tom Anderson <thomasanderson@google.com> writes:

Show 7 quoted lines

> On 05/02/2016 12:58 PM, Junio C Hamano wrote:
>> Tom Anderson <thomasanderson@google.com> writes:
>>
>>> Yes, but I like my stashes to be saved in the ref namespace.
>> Isn't that something you can do so yourself with store_stash?
>
> What I want can be achieved using "git stash store `git stash create`"

OK.

I am not strongly opposed to either a new option to create (i.e. "create --store" stores a new stash entry) or a new subcommand.

It just felt that a new option to "save" that deliberately breaks the basic premise of the command, i.e. "my working tree is a mess, and I want to revert it to the pristine state quickly to work on something else that is urgent, but I want to store the mess away instead of discarding, so that I can come back to it later", was totally out of place. I.e.

	work work work to create a mess
	git stash save
        work on a quick and urgent stuff, knowing that you are
        building on a solidly committed state
        git commit
        git stash pop
        continue building on the mess

is what "save" is about.

As your workflow is quite different (without "reset --hard", you no longer can rely on the resulting state to be pristine, suitable to work on something totally unrelated), it would have needed way way more explanation in the description section to describe this quite different mode of operation, as it is quite incompatible to the way traditional "stash save" users would want to use the command for if you do not revert the working tree to the pristine state. Instead you would do something else (which was not described--if the answer is "keep working, leading to the creation of the next commit", it is unclear what the resulting stash entry would be used for, as it obviously won't apply to that state, as the stashed change is already contained in that next commit).

"git stash save --keep" is bad enough already; it does not give the user pristine state wrt the current HEAD--what it does is a pristine state wrt the next HEAD that _would_ have resulted if the stuff you've been working on and decided are good by doing "git add" is all committed. In hindsight, it may have deserved a separate command to make it easier to explain to the end users.

Let's not make it worse.

This is a tangent, but I am not sure where your aversion to "reset --hard" comes from. If something was changed, mtime changes, and otherwise your build would break. It's not like "reset --hard" touches mtime for every path in the working tree including unchanged ones.