From: Junio C Hamano Date: Thu, 13 Nov 2014 21:06:50 GMT Subject: Re: [PATCH 2/2] Let deny.currentBranch=updateInstead ignore submodules Message-ID: In-Reply-To: Junio C Hamano 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.