On Wed, Jun 4, 2008 at 10:50 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > On Wed, 4 June 2008, David wrote: >> >> Thanks, but this doesn't quite solve the problem. I'm on the verge of >> figuring it out, and would appreciate any further tips :-) >> [snip] > I think the simplest solution would be to mark old master, change it > to topic (merge or branch -f), and use interactive rebase. > Thanks for the idea, but doesn't this make your 'master' branch very volatile? My understanding is that it's better to keep master as stable & "main line" as possible, and only merge into it when the bits being merged are relatively safe. In your example, you still have a TMP "rollback" point if you need to rewind master in the event that the merge into master goes badly. Maybe jumping master around like that works better when you're more experienced with git and can fix problems with master quickly. In my case I make rsync backups of my git repos before I do anything that looks remotely dangerous ;-) David. -- 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
