push all branches and tags at the end of a Git Town operation

[kevgo]

git push --all origin

[defunctzombie]

My preference as a user is to avoid pushing tags at the end of an operation. I've actually found myself searching for how to disable the behavior of git push --tags at the end of a git town sync operation.

I see in this comment: #2906 (comment) you have the following reasoning:

If you don't add any tags locally, running this command does nothing, so no problem.

If you intentionally add a new tag locally, it's better to try to push it to the server. Git tags are meant to be shared. Keeping your local Git workspace in sync with the rest of the world is Git Town's job.

My experience does not align with that same assumption. Because the upstream repo is a shared resource, what is pushed does influence what others see and the tags available. I can understand how tags are thought of similar to branches and if you share an upstream with branches, why not tags? I think for me that reasoning breaks down a bit when you think of git town as a branching workflow automation tool. Because my focus when using git town is around branches, I view the capturing and pushing of tags as bystanders to that workflow. I expect git town to work with my branches and not tags.

[kevgo]

@defunctzombie thanks for sharing your perspective! Can you please describe the specific reason why you don't want to share Git tags that exist on your local machine with the other developers?

[defunctzombie]

@kevgo from my perspective framing it as "don't want to share Git tags" is maybe attributing a different workflow than what I am expecting. When I use git town to work on feature branches my mental model is that I am working with branches. Tags are some other aspect of git and not the thing I am trying to think about with how it might or might not interface with the upstream repo(s). Maybe some folks have a workflow where ensuring tags are pushed is important; but that is not our team. I'd probably also be surprised if I thought it was a default folks wanted vs could opt-into if it was important for their workflow.

[kevgo]

Thanks for the extra info! I still don't understand why you want Git Town to not sync tags.

Tags are some other aspect of git and not the thing I am trying to think about with how it might or might not interface with the upstream repo(s). Maybe some folks have a workflow where ensuring tags are pushed is important; but that is not our team.

It sounds like you don't care about Git tags at all and don't use them in your development workflow. If I understood that correctly, why does it "bother" you that Git Town syncs tags? Why not simply ignore the tags that Git Town syncs?

Tags are typically used to label code releases. This can be useful in development when triangulating bugs reported by users. Here is an example:

• A user of Git Town reports a problem with Git Town. They use Git Town version 11.1.0.
• I cannot reproduce the bug on the main branch. This could mean the bug was fixed in the meantime, or that I don't know how to reproduce it.
• I check out the version of the code base that release 11.1.0 had: git checkout v11.1.0
• I can reproduce the bug on that version. Now I know how to reproduce it, and can verify that it is correctly fixed on the main branch.

Syncing of tags was added after Git Town users requested it. There hasn't been much discussion about Git tag support in the last couple of years. Most people seem to be okay with it.

In any case, it sounds like you want to support #3212. That's great to know and bumps the priority of that ticket!

[defunctzombie]

Tags are typically used to label code releases

I agree - which is why I would not want any random cruft from my machine making its way to the central repo. Maybe what I really want to say is that I don't want to implicitly push my tags in git town operations but I would not mind pulling the official tags from upstream.

[kevgo]

Thanks for sharing your perspective on tags. I see your point. I now agree that a feature that makes tag syncing optional makes sense.