On Wed, Apr 27, 2011 at 5:17 PM, Tom Willemsen <tom.willemsen@archlinux.us> wrote:
It looks like you did a rebase which made it a straight line history, but didn't actually rebase it onto master. The common base is still f1e476373 (use gitk/qgit/git log -g/tig/etc. to see this), way back from February 1st. Given that your public repository master branch is still pointing at an old commit, I'm guessing you need to take just a few more steps.
I think I understand what you mean, but could you please explain how this could happen or why your steps fix this.
It likely happened because you did a rebase -i, but since your local master branch "pointer" hadn't kept up with the actual master branch, it wasn't based off the current master branch. Not sure how to explain it more other than what I said before- look at the visual and read 'man git-rebase' which is pretty extensive, and/or find some tutorials on what rebase is and how it works on the interwebs.
1. Check in or git-stash all uncommitted changes to your branch. 2. git fetch origin (or whatever the remote name is for the main projects.archlinux.org remote) 3. git branch -f master origin/master (once again, use the right branch name, but I highly recommend making origin the upstream repository)
Why do you recommend against this? This is where I think git hosting services confuse the original intent. Before one click forks, you would clone a project's repo which automatically sets up the origin remote and the remote tracking branch master. Just think about the definition of "origin"- unless you have commit access to a project, you will probably never be pushing to the origin, in a sense.
I've confused myself before this way, I'm so used to doing `git pull origin master` and `git push origin master` and everything origin master on my own projects that I barely think about what I'm doing most of the time (I know, this is terrible, but I've never really used git in a way that other people are involved as well so everything is almost always only origin) and just put origin master everywhere automatically. The first thing you should do is take a step back so you don't have to do "origin master" ever again. When I `git pull`, it pulls origin/master automatically into master. When I `git push`, it automatically pushes master to origin for me. This little bit in .git/config does that for me, but you can set it up, it looks like, by doing `git branch --set-upstream master origin/master`.
[branch "master"] remote = origin merge = refs/heads/master
I've pull from the wrong remotes and tried pushing to the wrong remotes this way a couple of times and got very confused when this failed. But then I'm a total newbie in using git when other people involved.
4. git rebase master testresults 5. git push -f <yourremote> testresults
I've taken these steps, please let me know if it went right (I don't actually know what I'm looking at with git log -g and gitk doesn't seem to work (can't find 'wish'). Looks totally right now. And optdepends are your friend:
$ pacman -Qi git ... Optional Deps : tk: gitk and git gui -Dan