Force Confirmation for Dropping Changed Lines

Hi all,

Most of the time, when a later commit changes a line in an identical fashion during, say, a rebase, you want Git to silently continue by dropping the duplicate change from the later commit. I have a common (for me) scenario where I want Git to specifically ask me to resolve this "conflict" myself instead of simply assuming that the change has already been applied.

Let's say I have a file my-code.x that starts with a line indicating its version:

===== my-code.x ===== VERSION=1.2 line 1 line 2 line 3 =====

In my branch my-branch off of master, I make a change:

===== my-code.x ===== VERSION=1.3 line 1 line 2 line 2a line 3 =====

Now someone else makes a different change on master and pushes it ([1]):

===== my-code.x ===== VERSION=1.3 line 1 line 2 line 3 line 4 =====

When I rebase my-branch onto origin/master, I get no conflicts and everything seems fine ([2]):

===== my-code.x ===== VERSION=1.3 line 1 line 2 line 2a line 3 line 4 =====

Except that I should have used VERSION=1.4, not VERSION=1.3 because I made a change to my-code.x. Obviously, for a single file this is easy to remember/check but when it's hidden among lots of files and commits it becomes very hard to find these types of errors.

How can I force Git to not assume my change to the first line is "redundant"?

Cheers, Hilco

[1] Note that this someone is (correctly) using the same, new version of 1.3. [2] If my example is actually incorrect, then please just pretend there are no conflicts.

On Wed, Jan 25, 2017 at 2:16 PM, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:

My guess is that you probably want a custom merge driver for your file types. That's where I would look initially.

Thanks, Jake

On 25 January 2017 at 14:24, Jacob Keller <jacob.keller@gmail.com> wrote:

Mmm, that sounds complex. The "my-code.x" is made up so I could keep my example as simple as possible. In reality, it's Maven's POM files (pom.xml).

So there is no setting for any of this? There is no way to switch off auto merging for certain files?

On Wed, Jan 25, 2017 at 2:51 PM, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:

Not really sure, but a quick google search revealed https://github.com/ralfth/pom-merge-driver

Maybe that will help you?

Thanks, Jake

Jacob Keller <jacob.keller@gmail.com> writes:

Its readme seems to indicate that it is either solving a different problem, or solving the same problem with the opposite goal in mind, in that its goal seems to be to forcibly resolve what textually does not resolve cleanly by choosing sides with an arbitrary policy, so that humans do not have to get involved when they ordinarily would have to.

Hilco's goal sounded to me the opposite---to force conflict even when the two histories did what textually does resolve cleanly and require humans to get involved even when they ordinarily wouldn't have to.

On 25 January 2017 at 15:46, Junio C Hamano <gitster@pobox.com> wrote:

Yes, unfortunately, you are correct. This seems to do the exact opposite of what I want.

Before I start learning about custom merge drivers, is what I want even possible? If yes, would you happen to know some good examples of (custom) merge drivers? (Python, Ruby, Java are all okay.)

On Wed, Jan 25, 2017 at 3:57 PM, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:

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.

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.

Thanks, Jake

Jacob Keller <jacob.keller@gmail.com> writes:

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.

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.

On Wed, Jan 25, 2017 at 6:32 PM, Junio C Hamano <gitster@pobox.com> wrote:

Ok so that whole section of documentation is very confusing to me. Maybe it could be improved for more readability. I'll see if I can't help clear up some of my confusion.

Thanks, Jake

On 25 January 2017 at 18:32, Junio C Hamano <gitster@pobox.com> wrote:

Thank you, that's an improvement. :-) Unfortunately, it still completes the merge. Is there any way to simply get the

Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:

You can, but you need to write one yourself without relying on "git merge-file", because the whole point of the 3way merge we implement (including in that program) is "do not bother the user when both sides made the same change."