Tom Anderson <thomasanderson@xxxxxxxxxx> writes:
> On 05/02/2016 12:58 PM, Junio C Hamano wrote:
>> Tom Anderson <thomasanderson@xxxxxxxxxx> 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.
--
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