From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergey Organov Subject: Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does Date: Tue, 31 Mar 2015 20:03:45 +0300 Message-ID: <87iodhqetq.fsf@javad.com> References: <871tkblapv.fsf@javad.com> <55147D27.1060204@kdbg.org> <87lhidlebw.fsf@javad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Johannes Sixt , Sebastian Schuberth , Git Mailing List To: Junio C Hamano X-From: git-owner@vger.kernel.org Tue Mar 31 19:04:06 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ycza3-0003Yn-Gu for gcvg-git-2@plane.gmane.org; Tue, 31 Mar 2015 19:03:59 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753237AbbCaRDu (ORCPT ); Tue, 31 Mar 2015 13:03:50 -0400 Received: from mail.javad.com ([54.86.164.124]:40228 "EHLO mail.javad.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752135AbbCaRDt (ORCPT ); Tue, 31 Mar 2015 13:03:49 -0400 Received: from osv (unknown [89.175.180.246]) by mail.javad.com (Postfix) with ESMTPSA id CC8B8618C9; Tue, 31 Mar 2015 17:03:47 +0000 (UTC) Received: from osv by osv with local (Exim 4.84) (envelope-from ) id 1YczZp-0006Nz-RR; Tue, 31 Mar 2015 20:03:45 +0300 In-Reply-To: (Junio C. Hamano's message of "Tue, 31 Mar 2015 09:28:36 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Junio C Hamano writes: > Sergey Organov writes: > >> 1. How to calculate the set of commits to rebase. >> >> 2. How to rebase merge commits. >> >> Can we leave (1) for a while at its current state and focus on (2)? > > Perhaps. You would have to be careful though, so let me think aloud > a bit... Yeah, care should be taken indeed, and it's not trivial to foresee all possible troubles from changing to cherry-picking of merge commits. However, in general it looks like it's better to get some conflict to deal with from cherry-picking than to miss essential changes silently as it sometimes happens now. I also wonder if git remembers in merge commits what merge strategy was used? If not, then it's yet another argument in favor of cherry-picking. -- Sergey.