Re: Force Confirmation for Dropping Changed Lines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jacob Keller <jacob.keller@xxxxxxxxx> 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.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]