Git: Pulling from remote - 【StackMirror】|git

This is my setup: I work at home and in college and the remote is stored online. All 3 locations have three branches called, say, br1, br2 and br3. Nothing fancy, each branch at each workstation is the same. In other words, br1 at home, br1 at work and br1 at remote all correspond to the same branch etc.

Now, when I try to pull br2 at home, I get a message saying that I've to specify which branch I need to merge with. I know what is happening and how to correct it but I can't figure out why it is happening. Does git not merge with a branch of the same name? Do I have to create entries in the config file for every branch I have?

On a side note, what is the difference between git rm --cached and git reset --mixed?

2012-04-04 17:30
by kshenoy

What if you push to the remote repositories, perhaps - James Black 2012-04-04 17:32

did you create br2 at home and puhed it to remote from home - aschmid00 2012-04-04 17:33

@James git status reports that my working directory is clean and there's nothing to push. It asks me to merge the remote changes using git pull... back to square one : - kshenoy 2012-04-04 17:35

@aschmid00 To be honest I don't remember where each branch was created. All I know is last push to br2 was done at work - kshenoy 2012-04-04 17:37

git rm --cached removes one or more files from the index (scheduled to be removed on commit). git reset --soft: "Does not touch the index file nor the working tree at all, ..." and does not take path arguments. Did you mean git reset --mixed? There the big difference is that rm --cached schedules for removal but reset --mixed unstages, including "bringing back" a rm --cached - torek 2012-04-04 18:46

@torek Yes I meant reset --mixed Was thinking mixed but typed soft. Lets say I modified some files and added them to the staging area. Now if I do git rm --cached or git reset, won't the effect be the same - kshenoy 2012-04-04 19:20

Simplest example, check out repo with file A, do echo more >> A; git add A. If you then git reset A it goes back to modified-but-unstaged; but if you git rm --cached A it goes to deleted, with a new "untracked" file A (with your extra line added) lying around - torek 2012-04-04 19:48

i think what happened is that you created the branch locally and pushed it to the remote.
in this case the local branch does not have an upstream.

you can set the upstream with

git branch --set-upstream foo origin/foo

-u

--set-upstream

For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch..merge in git-config(1).

2012-04-04 18:38
by aschmid00

Note that --set-upstream requires a reasonably recent version of git (1.7, looks like). Also, note that there is now (post 1.7.4?) a --set-upstream option during push, i.e., you can push to create and set an upstream origin all at the same time - torek 2012-04-04 18:51

ok but why wouldn't you have the most recent git version? : - aschmid00 2012-04-04 18:57

You'd think... At $work I often have the stone knives and bearskins, some of the machines have Python 2.3 for instance - torek 2012-04-04 19:01

You work at the same place as I do - GoZoner 2012-04-04 19:03

@aschmid00 I push new branches with git push origin <name>. Won't that suffice - kshenoy 2012-04-04 19:12

try git push -u origin <name>aschmid00 2012-04-04 19:19

@Ronin420 that is exactly the point. that its not enough - aschmid00 2012-04-04 19:34

You dont have to manually edit the config files. I'd recommend to delete the branch and check out a tracking branch from scratch. Be careful so you don't have any local changes that needs to be pushed:

git branch -D br2
git checkout --track origin/br2

If you checkout remote branches with --track they will always be setup properly when pushing and pulling.

2012-04-04 17:43
by ralphtheninja

Magnus, I resolved it in the same manner. But I couldn't understand why I was getting that issue in the first place. Thanks for the tip with --track. Didn't know that : - kshenoy 2012-04-04 17:51

From one 420 to another : - ralphtheninja 2012-04-04 18:04

@MagnusSkog with the latest git you don't need to explicitly track a remote branch. if you checkout a branch it automatically tracks the remote branch - aschmid00 2012-04-04 18:36

Unless the configuration says otherwise, which it might. If branch.autosetupmerge is set to false, then --track is needed. But you're right, the default value is true and should be no problem if no one has mucked around with the settings : - ralphtheninja 2012-04-04 20:58