Hi, On 2012-04-29 at 06:57:51 [+0200], Joseph Groover <looncraz@xxxxxxxxxxx> wrote: > Umm.. wow.. sorry folks, that is just what happened when I rebased to > include recent changes from Haiku's main repo... Yup, that's the problem with rebasing: it is *not* meant for published branches (i.e. branches that other people might track and even base their own work on). What happens during a rebase is that all local commits are taken out of the repo, the branch is being updated with the remote changes and then all the local commits are being added back on top. Because of that (and because of git's commit hashes depending on the hash of the parent commit), all the hashes of your commits change. So, when you push your changes, all of your commits will be interpreted as new by the script that's sending out the commit mails. > Think I'll do it manually next time (create a patch, destroy & recreate > compositing branch, apply patch, push...). That doesn't make sense, though, as you'd just be doing manually what a rebase is doing automatically - on top of that, you'd loose all your individual changes, as they'd be lumped into one big patch. > Any suggestions to avoid that? Yes, instead of rebasing, you can merge changes from Haiku's master branch into your own: git checkout compositing (make your branch the current one) git merge master (bring over all changes from "master") This will add all new commits from master to your branch (next to your own, as a separate line of development) and then add a single (merge) commit joining the two lines of development. When you do it this way and push, only your own new commits and the merge commit will appear as new to the commit mail script (and anyone else tracking your repo). Hope that helps? cheers, Oliver