0

The issue

This sounds like a GitExtensions bug, to which I couldn't find specific info. I believe the issue arises when you have a bare repository with more than 1 branch. If you then push, you'll get a warning that if you choose to ignore you'll find the mess up branches. Or depending on how you push it, not even the warning comes up and it's doom everywhere!

Let's say we have 2 local branches called master and another. And the default origin set for pushing. After a regular push we'd also find origin/master and origin/another, that's all.

But after the doomed push, we'll find duplicated origin/master and origin/another plus origin/refs/heads/master and that's also duplicated. For every extra branch. And it's not like we're pushing all branches or something, nor are we using Multiple Branches feature.

In fact, after this happening, we can't even simply push without an error! (yes, using windows of course)

Pushing to \\\server\git\repo
error: dst refspec refs/heads/another matches more than one.
error: failed to push some refs to '\\\server\git\repo'

The problem becomes way evident when listing branches with git branch -r.

To fix it

We need to do something like this:

  1. Manually remove the refs/heads folder in origin. Some times it works just using git push origin :<branchName>, others we need to go more robust and directly into the folder. This is the hard step and main problem happens when those don't work...
  2. git fetch -p, for bringing origin changes to local.
  3. Eventually going through all clients and using git remote update. If needed, removing the same branches, one by one or by any means, like robustly and directly into the folder again. There's yet another problem in this steps, sometimes, which I can't diagnose yet.

The frequency

To us, this is a stated fact. Even though I haven't done many experiments to see what exactly causes it, it does happen in any of 5 machines using this repo, all configured the same way except for the bare.

And every single time it happens I have to run and find out on how to fix it. This time I decided to document it, since I could never find anything on the web specific enough.

Why

The question here is: why this happens, and how to prevent it? Is it even GitExtensions fault only? That sure happens, in our side, only with this specific scenario, in GitExtensions.

Community
  • 1
  • 1
cregox
  • 17,674
  • 15
  • 85
  • 116
  • Your refspec looks fishy. Shouldn't that be `+refs/heads/*:refs/remotes/origin/*`? – knittl Aug 31 '12 at 20:52
  • @knittl I'm not sure, haven't tried on command line. I've got enough issues which I can't properly fix as it is. But that's what Git Extensions show, in 2 different input fields: `*` and then `refs/heads/*` – cregox Aug 31 '12 at 20:56

1 Answers1

0

While dealing with another simpler rep, accidentally (also coincidentally and finally) found out the culprit!

Under .git/config we had these 2 lines for [remote "origin"]:

push = refs/heads/*:refs/heads/*
push = refs/tags/*:refs/tags/*

Simply adding this one to the top, solved all issues:

push = *:* # hack for git extensions

The reason for the 2 lines at first, was "pushing everything to the server", including tags and heads.

I believe, somehow, GitExtensions read those and change its own default behavior in a wrong manner (why would it get just the right side of the first setting?) and thus effectively doing this on every push:

> git push origin *:refs/heads/*

And boy, do I tell you, cleaning up that mess isn't any simple task!

Solved.

cregox
  • 17,674
  • 15
  • 85
  • 116