Update on sourcetree branches

I kept my silence as I had personal issues to handle. Now that it’s done, I can comment on what was going on.

To topdog and anyone else using sourcetree,
The branches that I was able to edit mysteriously came back. I’m pasting the screenshot so that you can be understand it well. Don’t ask me how / why it reappeared. It just happened.

Nina,
Have you seen this before?

The branches showing in the pink/red color are remote only. These are the ones you want to ditch, if I understand correctly?

You’ve already deleted them locally, but they still exist wherever your remote is (github etc.). Basically your git repository exists as a copy on the remote, but has its own “pointers” and names for which commits its branches reference, individually from your local ones.

On the far left hand side where you have the branches sidebar open - currently highlighting on master12 as the checked out branch - further down from there you should find another section called Remotes and within that the next level down is “origin”.

To be clear, I’m highlighting the same section with a yellow underline, but from another repo I have here:

If you look/expand there in your repo, that’s where you should find the branches for master, master2, …, master5 that are showing in pink/red. Right-clicking on those should give the option to (say for example) “Delete origin/master3” which will then act on the remote. Do that for each one you want to get rid of, but do take care not to remove those others it looks like you want to keep - e.g. origin/master8+

Topdog,
The situation is not as easy as you think:
Project A - this is my original. I make a duplicate called project B. From project B, I then modify certain things and send it to Github link B. Project B is then removed & github link B removed.

For your information, I already removed project B and github link some time ago. Those pink branches you saw disappeared nicely. It suddenly reappeared a few weeks later. So I prefer not to touch anything now.

So to be clear, project A branches never had any of those branches.

If the two projects point to the same remote it doesn’t matter if you think project A had them or not. They ARE there, and they are on the remote side.

That also means regardless of whether you have pulled those branches down into Project A or not, they can still be removed on the remote. They can also be reinstated on the remote.

I assure you it is easy, but perhaps you need to just accept they are there for now and come back to get rid of them later when you have had a chance to get some more experience. An experienced git / github user would resolve this in seconds - not to discredit you, it’s just admittedly an unintuitive system to work with as it has a lot of flexibility.

Also this problem likely wouldn’t even exist if you had stuck to leaving a chain of commits in a single branch, instead of putting a branch on each and every one. It’s the continued existence of the branches that allows those pink nodes to still stick around. I’ve advised against this since the beginning.

You don’t have to worry. I don’t feel silly / stupid. Of course an experienced person can solve this very fast. An experienced person can do lots of things I can’t do. That doesn’t surprise me at all. So can you explain why it came back after a few weeks instead of immediately? That puzzles me more than the branches still being in the remote.

Yeah and I didn’t mean to appear condescending or anything either; just that future you will realize it will be easy too.

I can only make guesses as to why they returned, those guesses would include:

  1. Something went wrong when deleting the branches from source tree and it may have appeared to show them gone temporarily but they still existed on the remote and could return on a future successful fetch.
  2. They just disappeared visually rather than actually through options like the “Show Remote Branches” checkbox at the top of the screenshot.
  3. Systems like GitHub offer the ability to “undo” the deleting of a branch on its side, which would reinstate it and make it appear on a subsequent fetch.
  4. As the repo’s are copies of eachother, even if they end up with different contents, it is possible to push from both - just as if you were 2 developers on 2 machines pushing to the same remote repo. Somewhere along the line if Project B still had references to those branches and an accidental push was done from it, it could reinstate them. This would be allowed since those branches and commits don’t clash with the contents of the remote or Project A. Subsequent fetches from the Project A repo would then start to see them again.

That might not be an exhaustive list but they are the type of reasons that can legitimately lead to this state.

I can only agree to your explanation on a theory scale. I did check the remote real carefully by clicking on every branch and making sure it corresponded to the branch i found. I did remove those locally but they were not on the remote ones. Reasoning is when i clicked on the remote, different branches were selected in the coloured branches in response to what i clicked on the left list of master branches. So it still doesn’t make sense. Anyway, I can try your idea again when i have time. That’s not a problem for me. Thanks for the information. You might not be wrong. If i find something new, I’ll share it here.

Privacy & Terms