Junio C Hamano <gitster@xxxxxxxxx> writes: > Thanks for an explanation why the updateInstead mode must require a > pristine working tree (and the index). I *now* agree why such a > mode would be useful, *after* reading it. I did not understand why > *after* reading only the patch, the documentation updates and the > log message. > > That tells us something, doesn't it? ;-) Just to be less cryptic, I meant that the documentation since v2 is probably insufficient. > I agree that a new value "mergeInstead" or something should be > invented when/if different workflows want a looser semantics. > People would rely not only on "being able to push when clean" but > also on "being safely prevented from pushing when not" (and that is > where my earlier comment to test both sides comes from). Loosening > the check to an existing "updateInstead" would break users who have > been using updateInstead. And thinking about the names again, I have a feeling that updateInstead and mergeInstead are both probably misnomer. The "make sure there is no modification and then do an equivalent of reset --hard there" option makes sense only in push-to-deploy scenario (perhaps "resetInstead"?) Compared to that, "do an equivalent of checkout as long as it can be done without involving real merges" sounds more deserving the "updateInstead" name. But I am not very good at names (and I suspect you feel you yourself aren't, either), so perhaps somebody listening from the sideline can chime in. -- 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