On Wed, Jun 4, 2008 at 10:50 AM, Jakub Narebski <jnareb@gmail.com> wrote:
quoted text
> 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]

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html