Re: checking for 'clean' bare repo before push

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 25, 2012, 05:35 UTC
Message-ID: <7vk3ywhs20.fsf@alter.siamese.dyndns.org>
In-Reply-To: <js6pnt$28f$1@dough.gmane.org>

Neal Kreitzinger <nkreitzinger@gmail.com> writes:

Show 16 quoted lines

> I'm being asked to provide commands to check for 'clean' state of bare
> repo before and after a git-push.  This request is based on the notion
> of checking for a clean worktree (git status) before a checkout,
> merge, etc on a non-bare repo and checking the worktree state after
> such operations.
>
> Context:
> Since the bare repo and non-bare clone repos in question only have
> branch master, and deny-non-ff is set for the bare repo, I don't think
> there are checks to be done before and after git-push in our
> case. git-gc and git-fsck could be possible, but don't seem normative
> for every single push.  git-gc has auto configurations, and git fsck
> is expensive.  It seems like routine git-gc obviates the need for git
> fsck.
>
> Am I correct on this?

I agree 100% with you that it is entirely unclear what 'clean'-ness your requestor wants from your description.

At a higher conceptual level, "before I do merge I want to check if the working tree is clean" is a wish to avoid "overwriting" things, and in that sense, perhaps the requestor wants to make sure that a push she accepts does not overwrite somebody else's work.

Such a 'clean'ness is called "fast-forward", and by default a push has to be a fast-forward to be accepted. The pusher can "force" a push that is not fast-forward, but there is a way to forbid such a forced push (receive.denyNonFastForwards).