From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_DKIM_INVALID, T_RP_MATCHES_RCVD shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 4644D1F576 for ; Tue, 13 Feb 2018 06:44:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933428AbeBMGoz (ORCPT ); Tue, 13 Feb 2018 01:44:55 -0500 Received: from mail.javad.com ([54.86.164.124]:52846 "EHLO mail.javad.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933366AbeBMGoy (ORCPT ); Tue, 13 Feb 2018 01:44:54 -0500 Received: from osv (unknown [89.175.180.246]) by mail.javad.com (Postfix) with ESMTPSA id 91E1B3E8B8; Tue, 13 Feb 2018 06:44:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=javad.com; s=default; t=1518504294; bh=E9KcywdQoz1mCuVqZ3E32LkMac0X54+NcmlM75C7TBg=; l=1518; h=Received:From:To:Subject; b=IHan9Rz6xQwh5FKm00MZLMlwI0VUOf25pb5tYrLtbJC2MY+btB/VtPHZsMv1bytNy EWXaElz3/oh3YFKgxDRTJYtgFwTlMt+OQRnsFH2zbvA7EUEMKnC8/A3uiRxqkGlyzW yu9o/XY3TPsLj76oaf/0g48PNMh8q4EQxp0UpipU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=javad.com; s=default; t=1518504294; bh=E9KcywdQoz1mCuVqZ3E32LkMac0X54+NcmlM75C7TBg=; l=1518; h=Received:From:To:Subject; b=IHan9Rz6xQwh5FKm00MZLMlwI0VUOf25pb5tYrLtbJC2MY+btB/VtPHZsMv1bytNy EWXaElz3/oh3YFKgxDRTJYtgFwTlMt+OQRnsFH2zbvA7EUEMKnC8/A3uiRxqkGlyzW yu9o/XY3TPsLj76oaf/0g48PNMh8q4EQxp0UpipU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=javad.com; s=default; t=1518504293; bh=E9KcywdQoz1mCuVqZ3E32LkMac0X54+NcmlM75C7TBg=; l=1518; h=Received:From:To:Subject; b=RfyulLm4z1sui1gH6/bthrnfXDMSpp3EXr0kgQsizd2Kvn6HMKMV20s1DrMjhsjgB XzkslNqAFh4SWNJyOQwgHPGp0T25rn2rYFnJ09s2aH62VlhIhzJiByasluVrpxjl3R h9ohDk/6J06p3o2LyyVzbBh4P1srQnBspnBHCnGM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=javad.com; s=default; t=1518504293; bh=E9KcywdQoz1mCuVqZ3E32LkMac0X54+NcmlM75C7TBg=; l=1518; h=Received:From:To:Subject; b=RfyulLm4z1sui1gH6/bthrnfXDMSpp3EXr0kgQsizd2Kvn6HMKMV20s1DrMjhsjgB XzkslNqAFh4SWNJyOQwgHPGp0T25rn2rYFnJ09s2aH62VlhIhzJiByasluVrpxjl3R h9ohDk/6J06p3o2LyyVzbBh4P1srQnBspnBHCnGM= Authentication-Results: mail.javad.com; spf=pass (sender IP is 89.175.180.246) smtp.mailfrom=osv@javad.com smtp.helo=osv Received-SPF: pass (mail.javad.com: connection is authenticated) Received: from osv by osv with local (Exim 4.84_2) (envelope-from ) id 1elUKh-0001wO-Ke; Tue, 13 Feb 2018 09:44:51 +0300 From: Sergey Organov To: Johannes Schindelin Cc: git@vger.kernel.org, Junio C Hamano , Jacob Keller Subject: Re: [PATCH 5/8] rebase: introduce the --recreate-merges option References: <71c42d6d3bb240d90071d5afdde81d1293fdf0ab.1516225925.git.johannes.schindelin@gmx.de> <874lmqirma.fsf@javad.com> <874lmmerdu.fsf@javad.com> Date: Tue, 13 Feb 2018 09:44:51 +0300 In-Reply-To: (Johannes Schindelin's message of "Mon, 12 Feb 2018 21:21:05 +0100 (STD)") Message-ID: <87bmgt8k2k.fsf@javad.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Hi Johannes, Johannes Schindelin writes: > Hi Sergey, > > On Mon, 12 Feb 2018, Sergey Organov wrote: > >> Thanks for explanations, and could you please answer this one: >> >> [...] >> >> >> I also have trouble making sense of "Recreate merge commits instead of >> >> flattening the history by replaying merges." Is it "> >> commits by replaying merges> instead of " or is it >> >> rather " instead of > >> replaying merges>? > > I thought I had answered that one. No, not really, but now you did, please see below. > > Flattening the history is what happens in regular rebase (i.e. without > --recreate-merges and without --preserve-merges). > > The idea to recreate merges is of course to *not* flatten the history. Sure. Never supposed it is. > Maybe there should have been a comma after "history" to clarify what the > sentence means. That's the actual answer to my question, but it in turn raises another one: why did you change wording of --preserve-merges description for this new option? > The wording is poor either way, but you are also not a native speaker so > we have to rely on, say, Eric to help us out here. Likely, but why didn't you keep original wording from --preserve-merges? Do you feel it's somehow poor either? Anyway, please also refer to wording suggestion in the another (lengthy) answer in this thread. -- Sergey