Re: [PATCH] stash: --keep option just saves

[Junio C Hamano <gitster@pobox.com>]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> I'm sorry. I didn't think about such a negative aspect of adding the
> feature.

No need to be sorry about anything, please.  Nobody has to apologise after
trying a constructive contribution to solve a perceived problem.

> I can imagine that, after using many 'stash save --keep', I'll naturally
> want to manipulate changes between kept stashes, like running 'git log'
> to view the difference between each step and cherry-picking a change
> between ones next to each other etc. Because a list of stashes doesn't
> support such operations, additional support for them is needed to make
> it useful, but I agree with you that such additions are not real
> features that are necessary, because git already supports these
> operations if I used commits on a normal branch instead. Use of 'stash
> save --keep' is making it necessary to implement duplicated features for
> no good reason.

That was exactly my point.  "save --keep" (or --no-reset) might look as if
it is a new convenience feature, but you will realize that it really is
not, once you think things through.  It is not new because there already
is a way meant to be used to snapshot before going forward (i.e. regular
commits on a private branch for experiment), and it is not convenient
because its results cannot be used as flexibly with existing tools as the
results by the other, existing approach.

It can be argued that it adds one huge convenience.  It is quicker to say
'git stash save --keep' than 'git commit -a -m "WIP as of $(date)"', and
in addition, you first have to do a "checkout -b wip" once, if you use the
approach with regular commits on a exprimental branch forked from the
target branch, instead of the approach with regular commits directly on
the target branch.

But if that convenience is the real motivation behind it, adding an option
"git commit --snap" that runs 'git commit -a -m "WIP as of $(date)"' would
be a far more superiour solution that does not have the problem of feature
duplication (and no, please do not suggest "git alias snap ..."; the point
is to make it easy to do this for *everybody* out of the box).

> It may also confuse users by unnecessarily adding another way to do the
> same thing.

I actually did not think of that issue, but you may be right.

>> This topic won't go beyond 'next' during this round because it started way
>> after -rc0 was tagged.  It is not urgent to decide what will happen to the
>> recent "snapshot" related topics, and we have plenty of time to toss ideas
>> around, but currently I have to say that I am not very enthused about any
>> of the causes mentioned in various discussion threads.
>
> You already applied my patch on pu branch. It's OK by me if you dropped it.

Rather, lets let a hundred flowers blossom and see what happens.  I will
promise it will not be followed by a purge ;-).