It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

`git branch -r` showing too many branches: 1,862 versus 433

if I run:

git branch -r | wc -l

in a local git sandbox that I created via a `git clone`, I will get approx 433 branches.

This is about (possibly exactly, but I didn't count them) what Bitbucket shows me if I go the branches page (and keep scrolling down).

So far so good, as I believe that is how many branches we currently have.


Now, if I go onto our Bamboo linux agent, and go into a directory that was created by one of my build plans, and run that same command, I get 1,862 branches.

Running, `git fetch --prune` seems to have no effect.


I've seen some articles that mention if the git sandbox was created with a `git fetch` (rather than a `git clone`) then `git fetch --prune` may not have any effect, but I need to have that command have an effect.


My Bamboo build plan gets the list of remote branches and operates on it, by creating a report full of information about "current" existing branches, along with some JIRA information.

Currently this report has 1429 plus branches that are not "current" and have since been deleted.

Thus my report has mostly wrong OBSOLETED information.


So the question is, what does Stash/Bitbucket do during the "checkout source code" step that prevents my running `git fetch --prune` effectively, and why would my newly created git sandbox on the Bamboo agent have old and outdated branch names?


I need some work-a-rounds to this issue.


Thank you.

3 answers

Are you cleaning up your workspace after builds?

Screen Shot 2016-02-18 at 10.21.42 AM.png

yes, I have clicked both boxes for cleaning up the work space, but this has no effect and has nothing to do with the problem at hand.

If I don't clean up the workspace, thus allowing my to log into that Linux agent, and `cd` into the build directory,

issuing `git fetch --prune` does nothing and

`git branch -r | wc -l` still shows 1800+ branches.

weird . . .


The old branches have been deleted on BitBucket?

via the Stash branch page which is about 20 pages of 25 branch names (around the 423 that I get from running `git branch -r | wc -l` on a pruned git sandbox on my laptop, or other co-worker's laptop), if i start typing any of the branch names that we know we don't have, the page turns empty. They aren't there. Nor are they there on a fresh checkout, using `git clone ...`.

So yeah, the command that Bamboo is using to get the source code, must not be `git clone` and there is something cached somewhere, such that when Bamboo does do the command to get the source code, it's getting it from this cached place, that has everything from the beginning of time.

(at least that's my interpretation of what's going on)

That's really strange.  my only thought - and I'm not sure it's a great one - is to delete the "Source Code Checkout" task and add your own git clone task as a "Script" task.  You'll need to muck about with authentication a bit, though, to get that to work.

I have done that as a workaround, as thankfully, I spent oodles of time a couple months ago "mucking" to get that (ssh) authentication to work.  I did that naively for a different problem that I didn't really have.

So yes,  doing my own `git clone` in a bamboo build plan, works exactly as doing it on my own laptop.

But I would like a slicker solution that leverages Bamboo's Source Code Checkout.

Maybe if Atlassian added a checkbox in the "SourceCodeCheckout" task, that would do a real `git clone` and no shortcuts.

Yeah - might be something to take to as a bug report / feature request (depending on how you look at it).  Post a link here and I'll vote for it.

Have you looked under "Advanced options" at unchecking "Enable Repository Catching on Remote Agents"?

that's a good idea (didn't even know there was an advanced options section.)

Everything is unchecked except for "Use shallow clones".

Aside: The Linux client that I am having a problem with, is a "local" client. Not a remote client, so maybe that check box wouldn't even apply to this problem.

And having said that, I will have to test to see if I have the same problem of where `git --prune` has no effect, or if the git sandbox is already un-cached (and pre-pruned) on our "remote" Windows clients.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Bitbucket

Share your software development horror stories!

Hey Community! I work on the Bitbucket product marketing team. With Halloween approaching, we wanted to discuss a topic tailor-made for October: development horror stories. Whether it was a lurk...

1,520 views 11 3
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you