6

I am trying to prevent co-workers to push again a tag in git that was deleted (because it was mistakenly pushed once).

I know how to do that locally and how to push it to remote and how to instruct my co-workers to do a pull the right way to prune the deleted tag from their local repository.

The problem is, it takes just 1 co-worker that does a push without first pruning and then the deleted tag is back and very soon all co-workers have the old tag back.

It is a nightmare to coordinate and ensure everybody does a pull with prune the exact right moment.

I suspect I have to resort to hooks. Any suggestions on how to resolve this in an automated way that do not require everybody to do a pull-with-prune the exact right time?

It has been suggested that this question has a solution, but that question merely discuss how to delete a remote tag. I am not familiar enough with git hooks to be able to solve this so pointers as to how to solve it with git hooks would be much appreciated.

Nicolai Henriksen
  • 1,324
  • 1
  • 13
  • 37
  • 1
    @leopal It is not exactly that. I edited the title at least, to prevent people misreading the question. – Acorn Apr 12 '19 at 09:45

1 Answers1

1

You can solve it with hooks, indeed, either client-side (since you control the machines of your co-workers), or server-side (best way). Other answers will probably help you with that.

However, a word on avoiding this: the proper way of handling this is not giving push permission to everyone in your company to begin with. Even if you want to have a centralized repository where everyone works (a bad idea), surely not everyone should be able to create production tags (a very bad idea). That is simply an anti-pattern that leads to problems like these.

Instead, the best approach is to have one or few developers/managers that review and accept changes (typically called pull requests). That way, you ensure mistakes cannot simply go through and that at least some degree of review occurs. Further, you can have a bot reviewing the pull requests for stuff like this, too; in the draft stage rather than in the final merge. For managing PRs, either use some of the well-known software/platforms or an email-based approach like the Linux kernel does.

Finally, another point: if the tag has been created, and this is a public repository (or a repo that other people can access, e.g. your clients), you really shouldn't be deleting it. Same principles as not deleting history that has been already pushed publicly. Deprecate the old tag and create a new one that supersedes it is the best approach.

Acorn
  • 24,970
  • 5
  • 40
  • 69
  • 3
    I strongly disagree with your approach of not giving permission. This might work for some companies and cultures but it is not approach for the world I live in. This is also an entirely different discussion. – Nicolai Henriksen Apr 12 '19 at 10:19
  • The tag needs to be removed. It was created in error and the commit is referenced by another tag with the right name. It is confusing to have that old tag. – Nicolai Henriksen Apr 12 '19 at 10:28
  • @NicolaiHenriksen I have helped several projects and companies where they follow that "approach", and it is simply broken. The same way it was broken in CVS and SVN, if you didn't have any access control to the main branches. It does not even scale: try doing that (or the equivalent in CVS and SVN) in a company with 300+ devs and you will see. (...) – Acorn Apr 12 '19 at 11:07
  • (...) Giving push permission to production branches, tags, etc. to every single employee in the company will end up, always, and without exception, in problems (as your own question proves). There is always an alternative, specially given we are talking about Git, which is particularly flexible. – Acorn Apr 12 '19 at 11:10
  • As for the tag: no, it shouldn't be removed. If you made a mistake, and you pushed it, and you didn't have any way of stopping that from reaching the main repo, the right approach is to live with it. Imagine you pushed sensitive information: there is no way of hiding it back. Still, if you want almost-pristine repositories, you need have a way to prevent errors; which is what my answer is about. – Acorn Apr 12 '19 at 11:13