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-Status: No, score=-3.6 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,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 B34971F5AE for ; Thu, 18 Jun 2020 10:14:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728377AbgFRKOv (ORCPT ); Thu, 18 Jun 2020 06:14:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728231AbgFRKOr (ORCPT ); Thu, 18 Jun 2020 06:14:47 -0400 Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D08F3C06174E for ; Thu, 18 Jun 2020 03:14:46 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id z1so3968821qtn.2 for ; Thu, 18 Jun 2020 03:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VVkgXQKYF30BnW/0ZNlY0omnqktdbH6w5r/2YIlZLAQ=; b=fO1KnyagkdldkjMko7JV6BrgG/I1AcYCDdQvnqYiNu5YSj6IABmM5I4LkV+bs+0SBw i5LxuCSQRbxyPT8ff5YO9BO3Zab6k9pf2RcQRT4v/1eGt+rBbFEPtpCoOHP+gbceG0ys wLXJEXFYYDUyayj/zvfNMfCO5ytg0h0JyiZzjyS9n4/ZN8yMFX/chLPa0tpsmwToYI8m vVPJ6ovlMtCl7owf9PRVWv7HfTmGgdsXig7JTHuCc6OMkk4Lqu9yBAx+O0Rn/41IAju8 VNmZClJqgyTxCYgGdehWKKsb8Zf9J/yV5Q/t5IY6sv8q+r8UmH4WnWCemNAE6K7CrWaw LIEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VVkgXQKYF30BnW/0ZNlY0omnqktdbH6w5r/2YIlZLAQ=; b=OiYpQoaL5xMEfKmL4NAc88FAdtrsnDxFfZSxsXoCu4RG+4Gia+g/FBAe1EKjQOxwdJ t2+HAlbW+xNJkAWvAewdjX+liBX7y9f5M47qJ4hWSdhpAzDrlX6BaS2TxfZssI8FFJYc 7YJDKXYvpijiN4AeQ6QGGSQ3zMkHZjBBJVzbZcs7Pt3safCeoJAgkHQjL0MLDymLL1HP 6Ovp2iOfenodyOHtQz/CuYvRAyeRDyWL0RCVlzRFqVfbpMSMb5zsXcHih/qoV4KwbcQm eUB6Up6KQCNXK9J2STj2QCmsGTbjUEA2xUzOM7FWUKXEbpiap3Py0+qD3s/CMxdqrbdz zVbQ== X-Gm-Message-State: AOAM530LyBw5DUcooDi31TLPpRkNzdKb70BktCdjSv6N1nimjJqe7WRO 0OkCe7BV6INFB9NPatdc6K/3rViinQb51KXN1O8= X-Google-Smtp-Source: ABdhPJwArOb8F+ohCoWmLvyje/DJUA5kBPtc02eHWbVRMIUouuJBjkUeooA1B9IE3D13169+wubVZliPPINfieVwiSw= X-Received: by 2002:ac8:31f3:: with SMTP id i48mr3627341qte.128.1592475284367; Thu, 18 Jun 2020 03:14:44 -0700 (PDT) MIME-Version: 1.0 References: <30661592138737@mail.yandex.ru> In-Reply-To: From: demerphq Date: Thu, 18 Jun 2020 12:14:33 +0200 Message-ID: Subject: Re: Collaborative conflict resolution feature request To: "Curtin, Eric" Cc: Konstantin Tokarev , Junio C Hamano , Christian Couder , "git@vger.kernel.org" , "Geary, Niall" , "rowlands, scott" , Michael Haggerty , "Coveney, Stephen" 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 Thu, 18 Jun 2020 at 11:28, Curtin, Eric wrote: > > > What I'd like to stress though is that there is a pitfall here: is it > > feasible to try to support concurrent conflict resolution, or is it to > > be sequential (even if in multiple turns)? I incline to the latter. > > > Concurrent conflict resolution would lead to conflicts in conflict > > resolutions, that already sounds too complex to be useful for my taste, > > and we already are in recursion that must be stopped somewhere, so it's > > tempting to stop it one level up. > > I think concurrent doesn't make sense, only sequential. > > > I find that the solution in these cases is to first use interactive > > rebase to squash and reorganize the commits in the branches so you > > have a nice clean patch sequence. Once you have the branches cleaned > > up and squashed into a sequence of reasonable topic based chunks you > > then merge, sometimes it even means you dont get conflicts at all, git > > merge is pretty smart. > > Again, as said in the initial email, anything that rewrites history, > recreates SHA's (such as rebase, squash, etc.) on a remote > branch is not allowed in our repo. Of course with unpushed > commits you can do some of these things as the remote end > knows no different. Ah I see, I missed that detail. We have a similar rule at work but only for the "trunk" branch (what most people call "master"), topic branches are allowed to change before the merge to trunk. I guess there is no way to convince your policy makers that if commit A and B are different but have the same tree hash they refer to the same state on the disk? I have had audit conversations like that. Anyway, sorry my reply wasn't helpful. Good luck. cheers, Yves