checking for 'clean' bare repo before push

checking for 'clean' bare repo before push

[Neal Kreitzinger]

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

Re: checking for 'clean' bare repo before push

[Junio C Hamano]

Neal Kreitzinger <nkreitzinger@gmail.com> writes:

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