custom merge driver vs. CONFLICT (delete/modify)

custom merge driver vs. CONFLICT (delete/modify)

[Sascha Silbe]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

Hi!

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)?

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: custom merge driver vs. CONFLICT (delete/modify)

[Jakub Narebski]

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

Re: custom merge driver vs. CONFLICT (delete/modify)

[Enrico Weigelt]

* Sascha Silbe <sascha-ml-reply-to-2010-3@silbe.org> 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 <side>) or always take one side (like -s <side>) 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
----------------------------------------------------------------------