pre-receive hook discussion to reject force push to git repository.

[RAJESHP]

Thanks for this discussion, (https://answers.atlassian.com/questions/224620/how-to-write-a-pre-receive-hook-in-bash-or-python)

I have a python pre-receive force push reject hook in place per the thread and it works as expected.

Here is a related question:

the upload of the "soon to be rejected object" has already happened, so the object will be still in the repository on the server, right ? in that case what is the GC schedule for stash ?

[cofarrell · Accepted solution]

Hi Rajesh,

That's correct.

Current Stash relies on the auto gc built into Git, which runs intermittently depending on how many loose objects there are in Git.

At some point I imagine Stash will need to get more sophisticate about scheduling the GC. There is also an addon that lets you do it manually:

https://marketplace.atlassian.com/plugins/com.atlassian.stash.plugin.stash-git-ops-plugin

It's worth mentioning that we change the configuration of a Git repository when you create your first fork due to the fact that we are using Git alternates (a way in Git share objects between repositories). Just something to keep in mind.

Either way I probably would worry too much about that rejected object unless disk space on your Stash server is a concern?

Cheers,

Charles

[RAJESHP]

Thanks and that was going to be my next question was about alternates. we were worried that in case of fork we would hit some issues with this approach and hence we disabled the forks for now, with a workaround to do a private repository with copy and go from there. (not optimal but atleast we think workable.)

the issue is that we do a fork of a repository and then in the master some one deletes the branch for e.g. then how will fork behave.? any comments ?

[cofarrell]

Hi Rajesh,

Deleting the branch should be fine - Stash forks are completely safe. But obviously the commits/blobs in the master repository will be unreferenced now, which is why we disable pruning (the cleanup part of gc) when you fork, so the repository will never shrink. We definitely plan on fixing this, but it's not trivial. For most people it's not a problem because 99% of the time commits end up on master and/or they don't use rebase.

I wouldn't be afraid of using forks unless you are expecting lots of large files to be pushed to Stash that you then reject. And even then I wouldn't be too concerned.

Cheers,

Charles