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,126
Community Members
 
Community Events
184
Community Groups

git push origin --mirror deleted all of my colleagues branches

Hi All,

 

I've just stupidly done a

git push origin --mirror

which mirrored my local repo to the remote deleting all of my colleagues work. Is there any way to revert to the remote repo state before I pushed my local repo?

Cheers

1 answer

0 votes
Julius Davies _bit-booster_com_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Jul 05, 2018

 

One idea:  get every colleague to just type "git checkout [branch]" and "git push" for every branch that matters to them.  They probably all have reasonably up-to-date local copies on their own machines.

Are you on Bitbucket Server or Bitbucket Cloud?  If you're on Bitbucket Server you might be able to painstakingly recover the lost branches by sifting through the server logs and recovering the commitId / branch associations.  Under the hood nothing is lost, but it can take days of menial (and error prone) log searching to recover the labels.

In the future, if you're on Bitbucket Server I recommend installing our free Control Freak for Bitbucket Server add-on, since it blocks pushes like this on the server-side right out of the box thanks to this setting (which defaults to enabled):

Block Multi-Rewrites [x] Yes [ ] No
Avoid push.default=matching disasters

With that setting in place your push would have (probably) been blocked with a warning like this:

remote: -----
remote: Push rejected. Multiple history rewrites
remote: in a single push not allowed.
remote:
remote: Is your "push.default" config is set to "matching"?
remote: Try setting it to "simple" instead.
remote:
remote: Trying to mirror a repo? In that case, disable
remote: "Control Freak for Bitbucket Server" for this repository.
remote: (Repository Settings -> Control Freak)
remote: -----

 I say "probably" because the push would have had to contain at least two history rewrites, which is highly likely with a "git push --mirror".   In future versions of Control Freak we plan to have this logic improved to also catch accidental "git push --mirror" scenarios that have no history rewrites.

Thanks for your reply. I think using fail safes in the future is a must and I will let our admin know about control freak. Atlassian have reverted the repo back to its original state from one of their automatic backups so all is good now!

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events