Michael J Gruber <git <at> drmicha.warpmail.net> writes: > > If you're on br1, I would: > > > > git rebase -i X^ > > # change "pick" to "edit" in front of X in the list you get > > git checkout X^ -- f3 f4 f5 > > git commit --amend > > git checkout X -- f3 f4 f5 > > git commit > > followed by > > git rebase --continue > > of course ;) > > > > > For the 2nd commit, using the -c option may be beneficial. > > > > Cheers, > > Michael > > > > Michael: Thanks so much for your help, this is a lot of fun! It occurs to me that another way (that doesn't use rebase) would be this: git branch -m br1 br1-old git checkout br1-old git reset HEAD~ git checkout -b br1 git add f1 git commit -m "f1" git add f2 f3 git commit -m "f2" git branch -d br1-old (history eraser button ;-) git checkout master git merge br1~ (which now only pulls f1's changes) (work for a while) git merge br1 (which now pulls f2 and f3). I like this sequence because it's so explicit about what's going on. Are there any conceptual problems going this route that I am missing that might screw up history? Chris Marshall -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html