Quoting Junio C Hamano <gitster@xxxxxxxxx> writes: > But I somewhat doubt if this line of change is a good idea to begin with. > > All talks about using stash --no-rest and snapshot share this problem. By > not making regular commits, you are denying yourself the rich set of tools > git offers you to use on regular commits and the ancestry chains between > them, and nobody explained what the benefits of not using normal commits > on normal branches are, nor how the inconveniences from this aversion to > branches forces you are justified by those unexplained benefits. I'm sorry. I didn't think about such a negative aspect of adding the feature. 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. It may also confuse users by unnecessarily adding another way to do the same thing. So I think you're right to point out that this is not a good thing to add. > 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. Thank you for your comments. -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ -- 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