Force Confirmation for Dropping Changed Lines

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

 



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.



[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]