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 differently. 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 issues | * 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 someday? 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 clone >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 :) Cheers! Cheers! 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 https://groups.google.com/d/msg/git-users/-/AWSL1fNwBjgJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
