Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >> Please tell a story where keep makes more sense than hard by enhancing the >> explanatory text <1> associated with this section. The current text says >> that the three topmost commit representing what you have recently worked >> so far are all unwanted, strongly hinting that hard is more appropriate >> thing to do than keep, which is not what we want if we are changing the >> example to use keep. > > Maybe the best story would be "you have just explored a blind alley > and decided the last three commits are not a good idea at all", with That unfortunately does not seem to describe the nature of the local changes at all, which I think is the whole point of this topic to encourage use of --keep over --hard. >> It would be sufficient to just hint that the uncommitted changes that you >> have in your working tree are unrelated to what these three commits wanted >> to do (e.g. you always keep small changes around, such as debugging >> printf's > > That use case is less interesting to me --- it is relatively harmless > to clobber such content. Actually I think that is the primary use case of the feature, as --keep was done as a parallel to the behaviour of checkout that checks out a different branch while keeping local changes. -- 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