From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id C31271F8C8 for ; Sat, 18 Sep 2021 14:19:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237762AbhIROUR (ORCPT ); Sat, 18 Sep 2021 10:20:17 -0400 Received: from smtp.hosts.co.uk ([85.233.160.19]:45165 "EHLO smtp.hosts.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231441AbhIROUQ (ORCPT ); Sat, 18 Sep 2021 10:20:16 -0400 Received: from host-84-13-154-214.opaltelecom.net ([84.13.154.214] helo=[192.168.1.37]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1mRbB2-00091V-3u for git@vger.kernel.org; Sat, 18 Sep 2021 15:18:48 +0100 To: Git List From: Philip Oakley Subject: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks? Message-ID: <01fe28d8-2887-bc42-c91b-c3237b5186a7@iee.email> Date: Sat, 18 Sep 2021 15:18:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Hi all, Is there a method within `git rev-list` to trim side branch merges where the merge's tree is identical to the first parent's commit-tree? One back-story: In the Git-for Windows repository, the previous releases are 'deadheaded' by merging with the upstream git, and simply taking the upstream's tree unconditionally. The Git-for-Windows `fixes` are then rebased onto that merge. This does mean that all the fixes keep repeating down the 2nd parent line. So, for example, grep'ing for changes can tricky with so much repeated chaff, but at least all old versions are directly in the history. Sometimes it's nice to 'pretend' (a simplified history) that there is only the one latest series of this 'long lived feature branch' (along with a similar desire for 'gfw/next` and `gfw/seen`). (one method has been to `git replace` that merge commit `{/"Start the"}` with it's parent on a temporary basis). >From my reading of the `rev-list` manual this is similar to the TREESAME capability, but without specifying any paths (maybe just `.` ?). * Is there an existing method for specifying that simplified history? * Is there a proper term for the treesame condition of the commit-tree (as recorded in the commit object)? * Thought's on adding an option for `--follow-treesame`? The desire also came up in my pondering about progressive/partial merges (how to represent/hold current state/history) of a large tree, whereby different authors take different 'bites at the melon' of merging a long lasting feature branch (the 'ball of mud' type), whereby the result could be an octopus merge of the main/feature/partial commits, which is repeated until the partial becomes a finalised merge (the book-ending and octo-merge is still wip, but would also benefit from the 'feature' merge technique used by GfW. -- Philip