Nanako Shiraishi <nanako3@xxxxxxxxxxx> 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 ;-). -- 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
