I think I found a way to sort it out. I deleted my local repo, then used the Clone function in SmartGit to start over
Max Hodges@DUCHESS /D/Documents/GIT-repos/wre-website2 (master) $ git branch -a * master remotes/origin/#1-google-analytics-jquery-tracking remotes/origin/#4 remotes/origin/HEAD -> origin/master remotes/origin/fix-search-label remotes/origin/fixed-livevalidation remotes/origin/master remotes/origin/new-product-detail-page now I have a local master branch again so I guess this should work. On Mon, Oct 15, 2012 at 11:10 AM, Max Hodges <m...@whiterabbitpress.com>wrote: > "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." > > > So "git fetch origin" is the only operation that touches remote branches? > That's a pull operation right? So Push doesn't actually commit anything to > remote branches? Remote branches are read-only (can pull from them, but > can't commit to them?) This sounds wrong because I didn't create any remote > branches. I only created branches locally then pushed them. Doesn't make > sense. > > > > On Mon, Oct 15, 2012 at 11:04 AM, Max Hodges <m...@whiterabbitpress.com>wrote: > >> Hi Damien, >> >> I tried the first step but I get an error which I don't fully comprehend >> >> Max Hodges@DUCHESS /D/Documents/GIT-repos/wre-website >> (fixed-livevalidation) >> $ git checkout --track -b master remote/origin/master >> fatal: git checkout: updating paths is incompatible with switching >> branches. >> Did you intend to checkout 'remote/origin/master' which can not be >> resolved as c >> ommit? >> >> Is there any other way to get my master back? or is the best way is to >> just delete the repo and start over by tracking changing from scratch >> again. >> >> Cheers! >> >> On Sun, Oct 14, 2012 at 5:14 AM, Damien Robert < >> damien.olivier.rob...@gmail.com> wrote: >> >>> >>> >>> 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 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.
