From mboxrd@z Thu Jan 1 00:00:00 1970 From: Enrico Weigelt Subject: Re: custom merge driver vs. CONFLICT (delete/modify) Date: Sun, 26 Sep 2010 16:37:32 +0200 Message-ID: <20100926143732.GA2984@nibiru.local> References: <1285445444-sup-3857@flatty.sascha.silbe.org> Reply-To: weigelt@metux.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: git X-From: git-owner@vger.kernel.org Mon Sep 27 04:55:58 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P03sf-0006Ni-SP for gcvg-git-2@lo.gmane.org; Mon, 27 Sep 2010 04:55:54 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932574Ab0I0Czt (ORCPT ); Sun, 26 Sep 2010 22:55:49 -0400 Received: from caprica.metux.de ([82.165.128.25]:44731 "EHLO mailgate.caprica.metux.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932305Ab0I0Czs (ORCPT ); Sun, 26 Sep 2010 22:55:48 -0400 Received: from mailgate.caprica.metux.de (localhost.localdomain [127.0.0.1]) by mailgate.caprica.metux.de (8.14.4/8.14.4) with ESMTP id o8R2q2N5018899 for ; Mon, 27 Sep 2010 04:56:37 +0200 Received: (from uucp@localhost) by mailgate.caprica.metux.de (8.14.4/8.14.4/Submit) with UUCP id o8QLctRk023820 for git@vger.kernel.org; Sun, 26 Sep 2010 23:38:55 +0200 Received: (from weigelt@localhost) by nibiru.metux.de (8.12.10/8.12.10) id o8QEbW0N031103 for git@vger.kernel.org; Sun, 26 Sep 2010 16:37:32 +0200 Mail-Followup-To: git Content-Disposition: inline In-Reply-To: <1285445444-sup-3857@flatty.sascha.silbe.org> User-Agent: Mutt/1.4.1i X-Terror: bin laden, kill bush, Briefbombe, Massenvernichtung, KZ, X-Nazi: Weisse Rasse, Hitlers Wiederauferstehung, 42, X-Antichrist: weg mit schaeuble, ausrotten, heiliger krieg, al quaida, X-Killer: 23, endloesung, Weltuntergang, X-Doof: wer das liest ist doof Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: * Sascha Silbe wrote: Hi, > For some files (those touched by rerunning auto*) I want the local > version to always take precedence. For some other files (autogen.sh, PO > files) I want the upstream version to take precedence. For all the rest > I want conflicts to produce an error. Perhaps you better should use an downstream branch (which is frequently rebased onto upstream), which removes the autogenerated files and then always regenerate them from scratch. This is what I'm doing in in the OSS-QM project [1][2]. I'm also making sure that the source tree follows a set of rules [3] which are IMHO necessary for clean build process and fix it if needed in my downstream branches. Looks like we're doing quite similar things - maybe put or efforts together ? :) > This has worked fine so far by using custom merge drivers, but while > adding the second one I encountered a problem: Merge drivers are only > invoked for modify/modify (and maybe add/add) conflicts. > More specifically a delete/modify conflict will cause git-merge to bail > out directly without calling the merge driver to resolve the conflict. Yes. I've sometimes encountered the same problem. Someone here already suggested using git-filter-branch for that. I'll yet have to investigate such an transformation process is stable against incremental updates (meaning: strictly deterministic - hashes stay the same on repeated imports), so the history stays intact. > Such a conflict occurred because the packaging people removed autogen.sh > (which is reasonable for them, but not for me). In this case you probably want the conflict, to see what's happening and react in a comprehensive way (eg. re-adding it). It could become even more interesting when they someday reintroduce it, because maybe an autoreconf call won't suffice anymore - in that case you'll also want to know about this, and the conflict is the wakeup call. > Is there a way to either resolve all kinds of conflicts in favour of > one side (like -X ) or always take one side (like -s ) for > a specific set of files? Even if it does not answer your question: maybe this isn't really what you originally want (go back to the root question: "what is the real purpose of my project ?") and makes more trouble than what you're trying to go around. Perhaps better don't touch these files at all, but always regenerate them on each build. cu [1] https://sourceforge.net/p/oss-qm/home/ [2] http://www.metux.de/download/oss-qm/normalized_repository.pdf [3] http://www.metux.de/index.php/de/component/content/article/57.html -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------