Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,559,390
Community Members
 
Community Events
184
Community Groups

Can you please make the default status of "Push all tags" option as unchecked?

Many of our company teammates are using the SourceTree as the Git client and it is pretty good in overall.

But regarding the tagging function, we're having a very annoying problem.

Normally we don't make a tag manually by each individual but the CI system makes some tags automatically when a new build is created.

Before we settled down with an agreed convention on tag naming, there were some experimentally created tags and we wanted to clear them out in order not to make an unwanted confusion. It looked just a simple straight forward thing, and removing them from the server and my local working copy was actually done easily.

However, since the Git is a distributed system the old wrong tags were already existed in other coworker's local repositories and because the default status of "Push all tags" option is 'Checked', those old tags were revived so many times when someone didn't sync their local tag with the remote server and pushed his/her commit with this option on, as the people didn't pay much attention on this option status and neither understand correctly what its impact is.

If once this situation happened we had to announce repeatedly to make sure this option is turned off and to sync their local working copy tags. 

I'm not so sure how many people are struggling with this issue but it was a surely annoying thing for us.

And so I want to know making its default status as unchecked would be acceptable for other users as well.

 

Best regards,

Oliver Cho

1 answer

1 accepted

2 votes
Answer accepted
Ana Retamal
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jan 03, 2019

Hi Oliver!

Thanks for sharing your idea and scenario with us, it will be interesting to know if there are more users that would benefit from this. Regarding your suggestion, I highly encourage you to submit it as a Feature request, that's the way our team acknowledges the wishes from our users and the way we track how many people is interested (by voting on the feature) You can submit it at https://jira.atlassian.com/projects/SRCTREEWIN/issues/ .

Hope that helps :)

Ana

Thanks Ana for your response.

I'll submit a feature request as well. Thanks. :-)

Oliver

Like Ana Retamal likes this
Ana Retamal
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jan 03, 2019

Thanks!

This backfired at my team as well. Please prioritize the change of the default. Thank you!

I also faced this problem while pushing the code then after un-checking "Push all tags", it got resolved.

This should be taken one step further and the "Push all tags" feature should be dropped outright.  This is dangerous.  Backfired on my team as well.  We push to git remotes as a method of deploying apps.  When the remotes for our deployment were added, Sourcetree started unknowingly deploying YEARS OLD tagged versions of our apps.  The worse part is there was no apparent indication that this was happening.  If it wasn't for a security monitor we have setup we might have never caught it.

To anyone else affected by this, I suggest commenting and voting on the open issue instead: https://jira.atlassian.com/browse/SRCTREEWIN-11146 

Like Oliver Cho likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events