Jacob Keller <[email protected]> writes:
> Setting the merge driver to "unset" will do what you want, but it
> would leave the current branch as the tentative answer and doesn't
> actually make it easy to resolve properly. That would only require
> putting "pom.xml merge=unset" in the .gitattributes file.
Where did you get that "unset" from? If that is this paragraph in
Documentation/gitattributes.txt:
Unset::
Take the version from the current branch as the
tentative merge result, and declare that the merge has
conflicts. This is suitable for binary files that do
not have a well-defined merge semantics.
you'd need to read the beginning of the file to learn how to declare
that an attribute is Unset for the path. merge=unset is setting it
to a string value, i.e. you are doing
String::
3-way merge is performed using the specified custom
merge driver. The built-in 3-way merge driver can be
explicitly specified by asking for "text" driver; the
built-in "take the current branch" driver can be
requested with "binary".
instead, specifying a custom merge driver "unset", which would
require something like
[merge "unset"]
name = feel-free merge driver
driver = filfre %O %A %B %L %P
recursive = binary
in your configuration file.
> That might be what you want, but it doesn't actually try to update the
> file during the merge so you'd have to hand-fix it yourself.
I think you should be able to do something like
$ cat >$HOME/bin/fail-3way <<\EOF
#!/bin/sh
git merge-file "$@"
exit 1
EOF
$ chmod +x $HOME/bin/fail-3way
$ cat >>$HOME/.gitconfig <<\EOF
[merge "fail"]
name = always fail 3-way merge
driver = $HOME/bin/fail-3way %A %O %B
recursive = text
EOF
$ echo pom.xml merge=fail >>.gitattributes
to define a custom merge driver whose name is "fail", that runs the
fail-3way program, which runs the bog standard 3-way merge we use
(so that it will do the best-effort textual merge) but always return
with a non-zero status to signal that the result is conflicting and
needs manual resolution.
