Junio C Hamano wrote: > Especially I did not check if there are > still undesirable data loss behaviour in corner cases that people > were worried about in the discussion. Check the tests. What am I missing? > In the longer term, it is unmaintainable to make such users (like > this new code) of the stash mechanism manually do so, and we may > want to add a "git stash __store" subcommand, not meant for the > interactive use of end users. The implementation of the stash > can later be changed without affecting such users by doing so. Yes, a "store" that stores a commit created with "create" would be nice. Why the horrible double-underscore though? "git stash create" is not meant for interactive use of end users either. > Perhaps "rebase" can be taught to be more careful when checking > if local changes may overlap with the changes being replayed. Frankly, I don't know if it's worth the effort. It might be a nice theoretical exercise, but what tangible benefit do I get as the end user (now that I have rebase.autostash)? In fact, I'll probably be slowing down the interactive rebase noticeably by executing a diff-tree at every step. And for what? > Those who still want to use stash would benefit from having an > autostash, but at that point, there is no reason to single out > "rebase" for the autostash feature. Those who want to stash > immediately before a "merge" that is known to conflict can use the > same autostash and may want to do so for exactly the same reason > they may want to use it for "rebase". Each command that wants to have autostash will have to implement it independently. You argued that an implicit merge.autostash may be harmful earlier: maybe an explicit --autostash; but at this point, the returns are diminishing: what is the great advantage of --autostash over a quick manual g ss, g sp (git stash save, git stash pop)? I don't know what problem you're trying to solve anymore. -- 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