All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.