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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 13, 2014, 21:06 UTC
Message-ID: <xmqqzjbuzu6t.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqq4mu2285w.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

> 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.

Show 7 quoted lines

> 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.