From: Jakub Narebski <jnareb@gmail.com>
To: Sascha Silbe <sascha-ml-reply-to-2010-3@silbe.org>
Cc: git <git@vger.kernel.org>
Subject: Re: custom merge driver vs. CONFLICT (delete/modify)
Date: Sun, 26 Sep 2010 03:17:19 -0700 (PDT) [thread overview]
Message-ID: <m38w2ohks3.fsf@localhost.localdomain> (raw)
In-Reply-To: <1285445444-sup-3857@flatty.sascha.silbe.org>
Sascha Silbe <sascha-ml-reply-to-2010-3@silbe.org> writes:
> I am (automatically) building snapshot packages by combining the packaging
> maintained in one repository (but also containing sources) with (more
> recent) upstream sources from another repository.
>
> 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.
>
> 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.
> Such a conflict occurred because the packaging people removed autogen.sh
> (which is reasonable for them, but not for me).
>
> Is there a way to either resolve all kinds of conflicts in favour of
> one side (like -X <side>) or always take one side (like -s <side>) for
> a specific set of files?
> Alternatively, is there a way to do a merge in multiple "steps",
> operating only on a subset of the files each time (so I can use
> -s <side> / -X <side> for two of three steps per merge)?
Well, you can create your own merge strategy (see git-merge-ours.sh
in contrib/examples/ as an example), put it in appropriate place,
and use '--strategy=<name>' to force using your own custom merge
strategy.
The problem you see is that merge *driver* (as set by gitattributes)
deals only with _file-level_ conflicts, i.e. it is run instead of
ordinary diff3-based merge. The CONFLICT(Delete/modify) is solved on
the _tree_ level by a merge *strategy*. Currently there is no way to
change how tree-level conflict is resolved, without creating your own
merge strategy. Though in princile it doesn't seem impossible...
--
Jakub Narebski
Poland
ShadeHawk on #git
next prev parent reply other threads:[~2010-09-26 10:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-25 20:43 custom merge driver vs. CONFLICT (delete/modify) Sascha Silbe
2010-09-26 10:17 ` Jakub Narebski [this message]
2010-09-26 14:37 ` Enrico Weigelt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m38w2ohks3.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=sascha-ml-reply-to-2010-3@silbe.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).