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=-4.0 required=3.0 tests=BAYES_00, 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 659121F5AE for ; Tue, 23 Jun 2020 16:16:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732975AbgFWQQX (ORCPT ); Tue, 23 Jun 2020 12:16:23 -0400 Received: from smtp.hosts.co.uk ([85.233.160.19]:54878 "EHLO smtp.hosts.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729562AbgFWQQV (ORCPT ); Tue, 23 Jun 2020 12:16:21 -0400 Received: from host-92-20-155-32.as13285.net ([92.20.155.32] helo=[192.168.1.37]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1jnlas-000Abd-4f; Tue, 23 Jun 2020 17:16:18 +0100 Subject: Re: Request for adding a simple mechanism to exclude files from Git merge operation To: Sergey Organov , "brian m. carlson" Cc: Tiran Meltser , "git@vger.kernel.org" , Amir Yosef References: <20200622194122.GN6531@camp.crustytoothpaste.net> <871rm6x86y.fsf@osv.gnss.ru> From: Philip Oakley Message-ID: <51924543-3e26-8340-2105-1d08adcea196@iee.email> Date: Tue, 23 Jun 2020 17:16:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <871rm6x86y.fsf@osv.gnss.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On 23/06/2020 13:44, Sergey Organov wrote: > "brian m. carlson" writes: > >> On 2020-06-20 at 18:21:40, Tiran Meltser wrote: >>> Hi, >>> This topic is quite common in various use cases (e.g. production >>> configuration vs. staging one) and there are quite a few talks about >>> it in the web. >>> Nevertheless, there is no specific solution to this problem, only >>> partial workarounds (including the famous merge driver “ours”). >> In general, this is a hard problem. When you perform a merge, you're >> asking to incorporate changes from both heads against a common merge >> base. What does it mean when you want to merge two branches together >> but not make any changes? Which version do you want, ours or theirs? > I believe we basically need support to apply different merge strategies > to different files. > > I had similar problem a few times when I merged a long-standing branch > and, after I saw the result of merge, I was basically satisfied, except > I needed to revert a few sub-directories of the project (that gave huge > number of conflicts), to their original state, either of my current > branch, or of the branch being merged, depending on particular case. You > see, I knew exactly what I needed, yet I was not able to achieve my goal > without resorting to nasty kludges. > >> Normally merges are symmetric, so if you want non-symmetric behavior, >> you have to define what it's supposed to be. > Yes, I'm ready to define what it's supposed to be. The problem is that > "git merge" won't let me, due to lack of support to apply different > merge strategies to different files. > > As I see it, first step of improvements could be to support > > git merge -- > > where selected strategy applies only to , and the rest of files > are kept intact (effectively applying "ours" strategy to them), So, essentially, for larger merges, this would be something like the recent `--pathspec-from-file=` series https://public-inbox.org/git/7324e091ba7f48e286e6c35c7b7c40490e5c85d1.1576778515.git.gitgitgadget@gmail.com/ by Alexandr Miloslavskiy for the commands that did allow files to be passed in via `--` lists. It would still require merge to be extended to include just a 'partial-merge' or a 'file-merge' to clearly distinguish what is happening! This still a symmetric merge, but with _author supplied_ pathspec limiting, which is implicitly "ours" for the paths that are not merged. (I don't believe that the pathspec file can have negative pathspecs, so..) > along > with > > git merge --exclude= > > , to be able to exclude specific files (apply "ours" only to them) > rather than include. One difficulty of .precious lists, whether embedded or local, is the false impression that they provide any form of security to the user, so it needs a name that make that clear. > > [ As a side-note, please notice that after such changes, the "ours" > strategy could be deprecated (not that I think it should), as either: > > git merge -- > > or > > git merge --exclude=. > > would do the trick. ] > > The next step would then be to support > > git merge --force -- > > that would force to re-merge with given strategy no matter what > their current status in the index is. Isn't this already the same as the restore/checkout? > > Even though such support would be enough for my specific use-case, it > doesn't provide suitable way to configure the default behavior. As a > more generic solution, a new syntax for "git merge" to specify what > merge strategy to apply to what files could be designed, and then > ability to put that syntax into a file for "git merge" to pick would > solve the problem of quasi-static configuration problem. Alternatively, > even more generic .gitignore way of doing things apparently could be > re-used to some degree by adding support for .gitmerge files. > > -- Sergey Philip