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.
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? 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. 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').
The force push has no ill effects for working branches unless other people are basing work off of it. force push is discouraged highly if you are a project maintainer on something like the master/maint branches, but forcing a push to a work branch is rarely frowned upon.
Ah thanks, that's good to know. Tom