threads / discuss / 44112

Switching branches not working in a cloned repo

Subject: Switching branches not working in a cloned repo

## tl;dr

5 messages between Sep 19, 2016 and Sep 19, 2016.

replies: 4people: 3as markdown or json

Paul Williamson· Sep 19, 2016, 13:58 UTC · lore

Hi,

We use git extensively on a number of repos. Recently, we have had a problem with one of them. This repo has a 'web_dev' branch. For copies of the repo cloned before a certain (recent but unidentified) time, we could 'git checkout' between master and web_dev and everything would be normal.

However, now if we clone the repo, we can no longer do 'git checkout web_dev'. Git doesn't complain, in fact there is no feedback and we are still in the master branch. Running 'git branch -r' still shows the branch as existing at origin.

If we try 'git branch web_dev' we then see web_dev listed locally and can switch to it BUT on closer inspection we realise that this action has created a new branch off master.

The first time we saw this was under Bash on Windows, so we thought maybe it was a beta problem, but a) other repos work as expected under that environment, and b) under cygwin, pulling the same repo to a new directory alongside an older copy shows that the problem occurs with the new clone, but not the one that that was cloned longer ago.

Also in this situation, there are no local outstanding code changes that might cause problems switching branches. This occurs right from a cleanly cloned repo.

It seems something has gone wrong with this repo, and we don't know what. It's a tough problem to google, and I was not able to search the gmane archives (DNS errors).

Any idea how to investigate?

Thanks, Paul

Philip Oakley· Sep 19, 2016, 16:16 UTC · re: Paul Williamson · lore

Re: Switching branches not working in a cloned repo

From: "Paul Williamson" <paul.williamson@mediamiser.com>

Show 11 quoted lines

> Hi,
>
> We use git extensively on a number of repos. Recently, we have had a 
> problem with one of them. This repo has a 'web_dev' branch. For copies of 
> the repo cloned before a certain (recent but unidentified) time, we could 
> 'git checkout' between master and web_dev and everything would be normal.
>
> However, now if we clone the repo, we can no longer do 'git checkout 
> web_dev'. Git doesn't complain, in fact there is no feedback and we are 
> still in the master branch. Running 'git branch -r' still shows the branch 
> as existing at origin.

Have you tried `git ls-remote` ?

The `branch -r` just lists the local 'rtb's (IIUC).

It could be someone has accidently pruned or deleted that branch at the remote.

What version are you (they) on?

Show 18 quoted lines

>
> If we try 'git branch web_dev' we then see web_dev listed locally and can 
> switch to it BUT on closer inspection we realise that this action has 
> created a new branch off master.
>
> The first time we saw this was under Bash on Windows, so we thought maybe 
> it was a beta problem, but a) other repos work as expected under that 
> environment, and b) under cygwin, pulling the same repo to a new directory 
> alongside an older copy shows that the problem occurs with the new clone, 
> but not the one that that was cloned longer ago.
>
> Also in this situation, there are no local outstanding code changes that 
> might cause problems switching branches. This occurs right from a cleanly 
> cloned repo.
>
> It seems something has gone wrong with this repo, and we don't know what. 
> It's a tough problem to google, and I was not able to search the gmane 
> archives (DNS errors).

Gmane had to quit. Try http://public-inbox.org/git (see the help link)

Show 5 quoted lines

>
> Any idea how to investigate?
>
> Thanks,
> Paul

-- philip

Paul Williamson· Sep 19, 2016, 18:01 UTC · re: Philip Oakley · lore

RE: Switching branches not working in a cloned repo

-----Original Message-----
From: Philip Oakley [mailto:philipoakley@iee.org]

>Have you tried `git ls-remote` ?
>The `branch -r` just lists the local 'rtb's (IIUC).

Nice, I didn't know about that command - I tried it though and it does list the remote branches correctly. I checked the commit refs given and it tallies with the refs at the gitolite server end.

>It could be someone has accidently pruned or deleted that branch at the remote.

I don't think so, as I say it's a gitolite server, so usually nobody is on it. We just push to it and set up post-receive hooks for if updates need to be pushed on to a deployment server.

Do you know of ways to check if anything is corrupted within the repo? I ran git fsck, but that didn't show up anything.

>What version are you (they) on?

1.9.1 at both ends (my laptop and our gitolite server)

> Gmane had to quit. Try http://public-inbox.org/git (see the help link)

Ah! Thanks. I tried searching but so far only turned up this thread.

> philip

Thanks for your reply, Philip.

Paul

Jacob Keller· Sep 19, 2016, 19:50 UTC · re: Paul Williamson · lore

Re: Switching branches not working in a cloned repo

On Mon, Sep 19, 2016 at 6:58 AM, Paul Williamson <paul.williamson@mediamiser.com> wrote:

Show 16 quoted lines

> Hi,
>
> We use git extensively on a number of repos. Recently, we have had a problem with one of them. This repo has a 'web_dev' branch. For copies of the repo cloned before a certain (recent but unidentified) time, we could 'git checkout' between master and web_dev and everything would be normal.
>
> However, now if we clone the repo, we can no longer do 'git checkout web_dev'. Git doesn't complain, in fact there is no feedback and we are still in the master branch. Running 'git branch -r' still shows the branch as existing at origin.
>
> If we try 'git branch web_dev' we then see web_dev listed locally and can switch to it BUT on closer inspection we realise that this action has created a new branch off master.
>
> The first time we saw this was under Bash on Windows, so we thought maybe it was a beta problem, but a) other repos work as expected under that environment, and b) under cygwin, pulling the same repo to a new directory alongside an older copy shows that the problem occurs with the new clone, but not the one that that was cloned longer ago.
>
> Also in this situation, there are no local outstanding code changes that might cause problems switching branches. This occurs right from a cleanly cloned repo.
>
> It seems something has gone wrong with this repo, and we don't know what. It's a tough problem to google, and I was not able to search the gmane archives (DNS errors).
>
> Any idea how to investigate?
>

Try a fresh clone with "git checkout --track origin/web_dev" and then a "git status -v" and let us know what happens. I suspect that older clones have the correct branches already setup for tracking, but the new clone isn't doing it automatically, so when you run git checkout web_dev you're just creating a new local copy.

You can probably fix this by running

git checkout web_dev git branch --set-upstream-to=origin/web_dev git reset --hard origin/web_dev

The last command will completely reset your local web_dev to match what's upstream, and the second command tells git that this branch tracks a given remote branch.

Hope this helps.

Regards, Jake

> Thanks,
> Paul
>
>

Paul Williamson· Sep 19, 2016, 20:13 UTC · re: Jacob Keller · lore

RE: Switching branches not working in a cloned repo

-----Original Message-----
From: Jacob Keller [mailto:jacob.keller@gmail.com]

>Try a fresh clone with "git checkout --track origin/web_dev" and then a "git status -v" and let us know what happens. I suspect that older clones have the correct branches already setup for tracking, but the new clone >isn't doing it automatically, so when you run git checkout web_dev you're just creating a new local copy.

Hi Jake, this worked!

Your explanation seems correct - I could still list the remote branches, thanks to the command that Philip suggested, but the linkage between the two was not there by default for some reason. Very strange, I have never seen that happen before.

Anyway, this solution is sound and seems to set everything (history etc) back to how it should be.

Thanks very much for your help!

Paul