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=-6.0 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD 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 A5ABE1FC96 for ; Tue, 6 Dec 2016 23:48:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752745AbcLFXsa convert rfc822-to-8bit (ORCPT ); Tue, 6 Dec 2016 18:48:30 -0500 Received: from mxo2.dft.dmz.twosigma.com ([208.77.212.182]:50104 "EHLO mxo2.dft.dmz.twosigma.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752469AbcLFXs3 (ORCPT ); Tue, 6 Dec 2016 18:48:29 -0500 Received: from localhost (localhost [127.0.0.1]) by mxo2.dft.dmz.twosigma.com (Postfix) with ESMTP id 731C1100055 for ; Tue, 6 Dec 2016 23:48:28 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at twosigma.com Received: from mxo2.dft.dmz.twosigma.com ([127.0.0.1]) by localhost (mxo2.dft.dmz.twosigma.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M2k9uf05VNQ for ; Tue, 6 Dec 2016 23:48:28 +0000 (GMT) Received: from exmbdft5.ad.twosigma.com (exmbdft5.ad.twosigma.com [172.22.1.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mxo2.dft.dmz.twosigma.com (Postfix) with ESMTPS id 60F368002E for ; Tue, 6 Dec 2016 23:48:28 +0000 (GMT) Received: from exmbdft7.ad.twosigma.com (172.22.2.43) by exmbdft5.ad.twosigma.com (172.22.1.56) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 6 Dec 2016 23:48:28 +0000 Received: from exmbdft7.ad.twosigma.com ([fe80::552e:5f62:35e9:7955]) by exmbdft7.ad.twosigma.com ([fe80::552e:5f62:35e9:7955%25]) with mapi id 15.00.1156.000; Tue, 6 Dec 2016 23:48:28 +0000 From: David Turner To: "git@vger.kernel.org" Subject: Merging .gitmodules files Thread-Topic: Merging .gitmodules files Thread-Index: AdJQGDIZC1844jW4SVmPzUNYlX6Zqg== Date: Tue, 6 Dec 2016 23:48:27 +0000 Message-ID: <8d266034ae5940efbec3eef372a6ce43@exmbdft7.ad.twosigma.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.20.60.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Consider two commits: one adds file A, and the other adds file B. These commits don't conflict; you can merge them with no problem. But if the two commits instead add submodules A and B, and you try to merge, you'll likely get a conflict in .gitmodules. This seems wrong; .gitmodules happens to be a plain text file as an implementation detail, but in terms of interpretation, it is more like a map of maps (name1 -> {path -> "...", url -> "..."}, name2 -> ...). We (Two Sigma) keep our .gitmodules file in alphabetical order (so we don't use git submodule add -- our .gitmodules file is instead generated by some more complicated offline process). But even for ordinary .gitmodules files, order is not important so long as it's consistent. I could set my .gitattributes for the .gitmodules file to use a custom merge driver. But: (a) I don't see an off-the-shelf one that does what I want ("union" happens to work in the add/add case, but not in the add/remove case or other cases) and (b) I would have to rewrite my whole history in order to have the .gitmodules file exist at every commit (or find a way to get .git/info/attributes into each of my users' clones) and (c) this should work correctly without customization; Git already treats the .gitmodules file as special for commands like "status"; there's no reason it shouldn't do so for merge and rebase. I'm not sure I'll necessarily have time to implement this -- for our use case ( http://github.com/twosigma/git-meta ), we might be able to get away with doing it in JS, and using something like https://github.com/mirkokiefer/diff-merge-patch#sets . But if I did have time, do others agree that it would be reasonable to special-case this file? (Naturally, before doing the merge, we would check that the file was in fact parseable as a git config file; merging two changed gitmodules files of which either is unparseable would fall back to merging as text).