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

[guy moore]

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?

Baffled.

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

Thank you.

[Tim Crall]

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

[guy moore]

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.

[Tim Crall]

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.

[guy moore]

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.

[Tim Crall]

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

[guy moore]

I created this: https://jira.atlassian.com/browse/BAM-17236

[Tim Crall]

Are you cleaning up your workspace after builds?

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

[guy moore]

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.

[Tim Crall]

weird . . .

The old branches have been deleted on BitBucket?

[guy moore]

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)