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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 3139C1F4D7 for ; Mon, 18 Apr 2022 07:05:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236901AbiDRHH3 (ORCPT ); Mon, 18 Apr 2022 03:07:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232340AbiDRHH1 (ORCPT ); Mon, 18 Apr 2022 03:07:27 -0400 Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 10B7CDC2 for ; Mon, 18 Apr 2022 00:04:48 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id o127so8238577iof.12 for ; Mon, 18 Apr 2022 00:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kapr040vmaKdpfCbTtD69N5qYkAGxoePakxueS0DZts=; b=XaDiXIY54XFTDTOEoywrJF+nTRMm+iA4Txepa8hoy4HBB8biyIiVMNGSB62ovcVhJz sWY09n45N6gsKkco0SxQCyoCdeSYuKttsNEa5QsxL2U9tviT27HAsyqm3mju3PVOe7SI x0ye4kV20duu/z4H1P12kyUJXO1V/v8csDQzkU/BFjglPVJ1sXnisamCoKFaYYw0Wc+J UGFNz4MbIBczSLQj/B9LE5u0X5CyV0zV4nUvLu/68JLFQtQlr6VnM6YzzHc1Ue5z4R6s rV5mxoKEJS4EqE+Nt6MW7iosNLbCy93a+UWp+8mRJz2U/IIfN0VVUzQc7W99kvR6JeUa mW3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kapr040vmaKdpfCbTtD69N5qYkAGxoePakxueS0DZts=; b=BwP+zqMZnpy87W8TD3RJD0Li2KaDXggmcN/bAv/GiwUfOPJEghDUqJWL18iC3XTZay HW+m2bS3rvJONMy4jsTgopQOhTaA1Vun8guq42Znjfj1c6++jAk7+/cG7acrccMKDdAi 8sFd3AultDlCPDHQCIo7ZOpvd+YQvdEwvRujVbQ+n1JeGT/GRLNno1uPCadIPijpMcl6 i1r1P7B3ZZeee+8un2LSXKoAtWyhxBGgg46J//2WCFG4EHv1PcFd/ryKXoKWmGhxpA33 k4GuwMOnDLjMCPodcKfx4+cSMUHrdlIizUKU1WgMeAW/ZcY+voRJIOM3KIQrPXiDOeuT Zhhw== X-Gm-Message-State: AOAM531vucykxjBRyMdLpAiVwjqR51SKoKzEfb8mZiZnC1x2psdUdNlR 7TZpIAHigGv5KLa6A4AUq1nudptflp9Zjno5+hv1QGCIGxPXtQ== X-Google-Smtp-Source: ABdhPJytJ4hZlzFqrSGU62y16e0pVsVUnFgB7GBB6O/W3C01k79PlrCD4Cdk5fcQwlE2q6pFh/fmNDgS6pZOIcu6H78= X-Received: by 2002:a05:6638:1450:b0:323:b114:c831 with SMTP id l16-20020a056638145000b00323b114c831mr4589438jad.285.1650265487418; Mon, 18 Apr 2022 00:04:47 -0700 (PDT) MIME-Version: 1.0 References: <20220413164336.101390-1-eantoranz@gmail.com> In-Reply-To: From: Edmundo Carmona Antoranz Date: Mon, 18 Apr 2022 09:04:36 +0200 Message-ID: Subject: Re: [RFC] introducing git replay To: Martin von Zweigbergk Cc: Elijah Newren , Junio C Hamano , Git List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Sun, Apr 17, 2022 at 7:23 PM Martin von Zweigbergk wrote: > > > My (Git-compatible) VCS [1] is very relevant to this thread. It always > treats the contents of a merge commit as the diff compared to the > re-merge (auto-merged) parents. That applies to diffs (like > --remerge-diff) and rebases (what Elijah suggested in that link above) > . An important part of the solution I went with is to store > information about conflicts in the commits. Note that it's a more > high-level representation of the conflicts - not conflict *markers* - > that's stored in the commits [2]. Adding a new kind of object type is > obviously a huge step to take for Git, but perhaps you can consider it > as long as these objects are not exchanged. Also, as you have probably > noticed with your `git replay` command, this kind of rebasing without > touching the working copy or trees can get pretty fast. I didn't see > any performance numbers in your original message, but you are probably > able to rebase >1k commits per second in the git.git repo [3]. > Thanks for all your input (I mean, everybody who has jumped into the conversation). In my last experiment to get this into rebase (and still without moving the working tree), the 900+ commits that make up the segment v2.35.0..v2.36.0-rc1 are converted in some 143 ms in my computer, which is an aging dinosaur.