Re: [PATCH 2/2] Let deny.currentBranch=updateInstead ignore submodules

Junio C Hamano [off-list ref] 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.