On Wed, Apr 27, 2011 at 3:54 PM, Tom Willemsen <[email protected]> wrote: > Hey Guys, > > On 20 Apr 20:32, Dan McGee wrote: >> Second thing is- wondering if you could rebase your work on the latest >> code. You branched quite a while ago and I'd prefer one line of clean >> code that applies nicely, as it is a lot easier to follow. Something >> like "git rebase master <mybranch>" should do the trick. It would also >> be great if you could use "git rebase -i" or any other tricks to >> squash fixup commits into the proper commit where that work originally >> belonged. > > Another one of git's nice features, it was interesting to work with > "git rebase -i", I did have to "git push --force" afterwards, though, so > I don't exactly know how that will affect repositories that have been > cloned before I did that, but I imagine it will make a big mess of > things.
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. 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) 4. git rebase master testresults 5. git push -f <yourremote> testresults 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. -Dan
