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.4 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 shortcircuit=no autolearn=ham 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 82C851F404 for ; Mon, 16 Apr 2018 22:55:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752040AbeDPWz0 (ORCPT ); Mon, 16 Apr 2018 18:55:26 -0400 Received: from mail-ua0-f171.google.com ([209.85.217.171]:34022 "EHLO mail-ua0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751161AbeDPWzU (ORCPT ); Mon, 16 Apr 2018 18:55:20 -0400 Received: by mail-ua0-f171.google.com with SMTP id t4so5533609ual.1 for ; Mon, 16 Apr 2018 15:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=44xPfZrtRm6Vh666Fzo/dLAcJ94SwGlJf4FZ+NQSsZQ=; b=A3RjhGoWKkuXznmwuR0BfhsCEvMZiFxEkK6ob6W3L1RsL5fEWNp5omQAXrQ2CQlxXi 0qUSjT4nO5fZC9kc2BIYbhogx/BPiFePDkXF+vsjLYtqvBPzcpaWHWWJTSkfA6qTJoQY n8eGXm5HPheChBGmXilkYyFhZU/eZrKDGBn4PitKluJ+HnhCGukAX01KDB+hTfs+Ylyd hzGLG2Ze8vQeJLlGcqy63btXkQAry6uPZ7LNgruDJocoV46RCrDSIEXfTekkJ3owD5Gi 41KdFz05lJw3VmfI9DnED4/dqYfsncySak2lEiW69NNtPsqxDDNTPwO0dK2ziE8Kokee piug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=44xPfZrtRm6Vh666Fzo/dLAcJ94SwGlJf4FZ+NQSsZQ=; b=U0u5/aSuIRhGV+N0YlkfRQ7D3Tq8LeIHov83j09S3c6h3bPW66L9AcRMhIG29fFfu4 3H5vmP7mT34tQ9/uO3NQoT41eH7yyKXQe3E79jy7Oxm59KLQLGNxjajCWAmS+fbr8bC3 O0nXcAZSbIRWRjGTgefoJ3gOdIwmaRrQk7d2fy6yRffvwdabBW/HCzVJWisdKYrt4Mk4 rR/6vlPqXPuetcHpptBQyd6e+ShSU3W2SQAcH152g9Qi0dDZmNSzDDH7Egb6dtaXHHj9 oS5FI6KaBVxWo+BM0GwMtgN6TzDDOQAbeFF5VgiQD2bn6hk4pQhGfiZSeXlMgUnserOt z5DQ== X-Gm-Message-State: ALQs6tA3wDsfiZ7VvtDJtKfH8SI/rc89LCRKxOOr19fwBSVRi5hkp/+z mz8Nwbb5ic8JqKgBSNzN4oHF3a62C2AcZ8Ratdo= X-Google-Smtp-Source: AIpwx48ZlTne11a8O/RwsQlkNrEx3cCtTOJ38rC1Vi5kZ6nn/jQoRqKm4CZH8N080hLl+fjvPQxY86mkyOGVoroqlE8= X-Received: by 10.176.20.201 with SMTP id f9mr5514880uae.29.1523919319973; Mon, 16 Apr 2018 15:55:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.42 with HTTP; Mon, 16 Apr 2018 15:55:19 -0700 (PDT) In-Reply-To: References: From: Elijah Newren Date: Mon, 16 Apr 2018 15:55:19 -0700 Message-ID: Subject: Re: Optimizing writes to unchanged files during merges? To: Linus Torvalds Cc: Junio C Hamano , Git Mailing List Content-Type: text/plain; charset="UTF-8" Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Sun, Apr 15, 2018 at 7:03 PM, Linus Torvalds wrote: > On Sun, Apr 15, 2018 at 6:44 PM, Junio C Hamano wrote: >> One thing that makes me curious is what happens (and what we want to >> happen) when such a "we already have the changes the side branch >> tries to bring in" path has local (i.e. not yet in the index) >> changes. For a dirty file that trivially merges (e.g. a path we >> modified since our histories forked, while the other side didn't do >> anything, has local changes in the working tree), we try hard to >> make the merge succeed while keeping the local changes, and we >> should be able to do the same in this case, too. > > I think it might be nice, but probably not really worth it. > So I don't think it's a big deal, and I'd rather have the merge fail > very early with "that file has seen changes in the branch you are > merging" than add any real complexity to the merge logic. That's actually problematic, and not yet possible with the current merge-recursive code. The fail-very-early code is in unpack_trees(), and it doesn't understand renames. By the time we get to the rest of the logic of merge-recursive, unpack_trees() has already written updates to lots of files throughout the tree, so bailing and leaving the tree in a half-merged state is no longer an option. (The logic in merge-recursive.c is excessively complex in part due to this issue, making it implement what amounts to a four-way merge instead of just a three-way merge. It's gross.) So, if we were to use the brute-force scheme here, when renames are involved, we'd need to have some special logic for handling dirty files. That logic would probably include checking the original index for both modification times (to determine if the file is dirty), and for comparison of contents. In short, we'd still need all the logic that this scheme was trying to get rid of in the first place.