checking for 'clean' bare repo before push

Neal Kreitzinger· Jun 24, 2012, 10:21 UTC · lore

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?

v/r, neal

Junio C Hamano· Jun 25, 2012, 05:35 UTC · re: Neal Kreitzinger · lore

Re: checking for 'clean' bare repo before push

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