On Friday, October 12, 2012 8:37:24 AM UTC+2, maxhodges wrote:

> I just deleted my local master so I guess I can merge the remote/master 
> forward and that will become my new master?

No, it will just merge it to the branch you do the merge on (git does not 
force you to track a remote branch remote/origin/master under your local 
branch master). What you can do is git checkout --track -b master 
remote/origin/master, which will create a local master branch that points 
to the same commit as the remote master branch. The track option tells git 
pull that it should update the remote master branch while you are on the 
local master branch.

> [remote "origin"]
> fetch = +refs/heads/*:refs/remotes/origin/*
> url = g...@bitbucket.org:maxhodges/wre-website.git

This line tells git that git fetch origin fetches all the branches in 
bitbucket.. and stores them under refs/remotes/origin/
(a simple git fetch is equivalent to git fetch origin)

> [branch "#4"]
> remote = origin
> merge = "refs/heads/#4"

This line tells git pull that once it has fetched all the branches in 
origin, it should merge #4 with the remote #4 branch 

> [branch "#4-2"]
> remote = origin
> merge = "refs/heads/#4"

This line tells git exactly the same, in particular both the #4 branch and 
#4-2 branch will point to the same commit after git pull --all

> [branch "facebook-comments"]
> remote = origin
> merge = refs/heads/master

Here git pull on branch facebook-comments will merge the remote branch 
origin/master. As you can see you can name the local and the remote branch 

Here you can see (partially) how commits seem to apply to multiple branches 
(but the results are cut off in the log)
$ git log --all --oneline --graph --decorate
* f2cdb49 (HEAD, origin/fixed-livevalidation, fixed-livevalidation) fixed 
| * 963706f (origin/fix-search-label, fix-search-label) fixed label 
position on
| * e061be1 fixed #21 firefox label issue
* f917121 (origin/master, master, facebook-comments) changed main message
*   6f12bd2 Merge branch 'revert-svpply' into facebook-comments

This is perfectly normal. Remember that under git commits are snapshots of 
your repo, and branches are only pointers to a snapshot. So in particular, 
given your config, branch #4, branch #4-2 and branch remotes/origin/#4 will 
all point to the same commit after an update.

> I guess I should avoid deleting local branches, to "clean up", if they 
were pushed to the remote repo, because they will > just get pulled again 

If you do a git fetch, it will fetch all the branches from bitbucket under 
remotes/origin/*, so yes these will be recreated.
Origin is the default name of the remote you had when you first used git 

>Any else obvious I can do to try and sort things out? I'm sure the tool 
works like it is supposed to, and the problem is >that I don't understand 
it all well enough. I'm trying to get some training scheduled, but we have 
to keep working on our >project meanwhile.

Everything look perfectly normal :)

On Thursday, October 11, 2012 1:58:21 AM UTC+9, Konstantin Khomoutov wrote:
>> On Wed, 10 Oct 2012 08:10:51 -0700 (PDT) 
>> > I have a git repo with multiple "origin" branches. 
>> Do I understand right that you have a configured remote named "origin" 
>> (either by creating that repo via cloning, which created such a remote 
>> automatically or by running something like `git remote add origin URL`), 
>> and you do fetch from that remote so Git created the so-called "remote 
>> branches" to track state of that remote repository for you? 
>> If this is indeed the case, such branches are named "remote branches". 
>> Yes, the name is confusing, but better stick to this universally 
>> agreed-upon naming convension so everyone things about the same things. 
>> > WHen I add a new branch and commit changes, it shows that each of 
>> > these branches are identical, so it may be writing the commits to 
>> > multiple branches. 
>> Impoissible unless you commit using a tool which does something wicked. 
>> Committing in plain Git only updates the HEAD reference and also an 
>> appropriate branch reference, if HEAD points to a branch.  So it's 
>> impossible to update several branches at one when doing a commit -- 
>> only the currently checked out branch is updated (the most usual case) 
>> or no branch at all (but ignore this for now). 
>> Well, it's also possible to do anything by writing a post-commit hook, 
>> but I also doubt this is your case. 
>> Another possibility is that what you tell us here is not what you 
>> actually do.  Note that Git does *not* touch remote branches unless it's 
>> performing `git fetch origin` which is specifically meant to download 
>> all the history from origin, not present in the local repo, and update 
>> the remote branches accordingly. 
>> > I think made I made some rebase mistake. 
>> I cannot imagine a way in which rebasing might break something in a way 
>> you describe.  Note that 
>> > Is there anyway to sort this out, it doesn't work like it used to and 
>> > its confusing. Or should I just delete the repo and start tracking 
>> > with a new repo? 
>> Start from pasting here the contents of your .git/config followed by 
>> the output of `git branch -a`. 
>> Next, paste the first handful of relevant lines of output generated 
>> by running `git log --all --oneline --graph --decorate` 
>> then commit to a branch (be sure to tell us which branch you committed 
>> to) and then paste the output of that `git log ... --graph ...` once 
>> again so we could naturally see what happened. 
>> Otherwise we're condemned to do plain guessing. 

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to