Re: Force Confirmation for Dropping Changed Lines

[Junio C Hamano]

Hilco Wijbenga  writes:

> On 25 January 2017 at 18:32, Junio C Hamano  wrote:
>> 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.
>
> Thank you, that's an improvement. :-) Unfortunately, it still
> completes the merge. Is there any way to simply get the
>/ markers?

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."

Re: Force Confirmation for Dropping Changed Lines

[Hilco Wijbenga]

On 25 January 2017 at 18:32, Junio C Hamano  wrote:
> 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.

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

Re: Force Confirmation for Dropping Changed Lines

[Jacob Keller]

On Wed, Jan 25, 2017 at 6:32 PM, Junio C Hamano  wrote:
> Where did you get that "unset" from?  If that is this paragraph in
> Documentation/gitattributes.txt:
>

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

Re: Force Confirmation for Dropping Changed Lines

[Junio C Hamano]

Jacob Keller  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.

Re: Force Confirmation for Dropping Changed Lines

[Jacob Keller]

On Wed, Jan 25, 2017 at 3:57 PM, Hilco Wijbenga
 wrote:
> On 25 January 2017 at 15:46, Junio C Hamano  wrote:
>> Jacob Keller  writes:
>>
 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?
>>>
>>> Not really sure, but a quick google search revealed
>>> https://github.com/ralfth/pom-merge-driver
>>>
>>> Maybe that will help you?
>>
>> 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.
>
> 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.)

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

Re: Force Confirmation for Dropping Changed Lines

[Hilco Wijbenga]

On 25 January 2017 at 15:46, Junio C Hamano  wrote:
> Jacob Keller  writes:
>
>>> 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?
>>
>> Not really sure, but a quick google search revealed
>> https://github.com/ralfth/pom-merge-driver
>>
>> Maybe that will help you?
>
> 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.

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

Re: Force Confirmation for Dropping Changed Lines

[Junio C Hamano]

Jacob Keller  writes:

>> 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?
>
> Not really sure, but a quick google search revealed
> https://github.com/ralfth/pom-merge-driver
>
> Maybe that will help you?

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.

Re: Force Confirmation for Dropping Changed Lines

[Jacob Keller]

On Wed, Jan 25, 2017 at 2:51 PM, Hilco Wijbenga
 wrote:
> On 25 January 2017 at 14:24, Jacob Keller  wrote:
>> On Wed, Jan 25, 2017 at 2:16 PM, Hilco Wijbenga
>>  wrote:
>>> How can I force Git to not assume my change to the first line is 
>>> "redundant"?
>>>
>>
>> My guess is that you probably want a custom merge driver for your file
>> types. That's where I would look initially.
>
> 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?

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

Maybe that will help you?

Thanks,
Jake

Re: Force Confirmation for Dropping Changed Lines

[Hilco Wijbenga]

On 25 January 2017 at 14:24, Jacob Keller  wrote:
> On Wed, Jan 25, 2017 at 2:16 PM, Hilco Wijbenga
>  wrote:
>> How can I force Git to not assume my change to the first line is "redundant"?
>>
>
> My guess is that you probably want a custom merge driver for your file
> types. That's where I would look initially.

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?

Re: Force Confirmation for Dropping Changed Lines

[Jacob Keller]

On Wed, Jan 25, 2017 at 2:16 PM, Hilco Wijbenga
 wrote:
> How can I force Git to not assume my change to the first line is "redundant"?
>

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

Thanks,
Jake

> 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.

Force Confirmation for Dropping Changed Lines

[Hilco Wijbenga]

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.