threads / discuss / 11154

When a merge turns into a conflict

Subject: When a merge turns into a conflict

## tl;dr

2 messages between Dec 6, 2007 and Dec 6, 2007.

replies: 1people: 2as markdown or json

Anand Kumria· Dec 6, 2007, 04:49 UTC · lore
Hi,

I've just had an odd experience with git (1.5.3.1) and wondered if this was a known issue.

One of my co-developers has a project, with a README.txt file. I branch from it and begin some edits:

	- make it more AsciiDoc like (ala git)
	- put in the README.txt a few patches that need to be applied
I had no issues 'git add' the file, and performing changes.

However when my colleague came to merge my patches in; git complained that the file had conflict because:

	a. it found the ========= AsciiDoc header line
	b. it found the diff markers in the file

I do not know git well enough to know if this is a heurestic that can be tweaked via the config file or something else. I am presently learning git-filter-branch so I can prepare something to show -- but I just wanted to flag and see if anyone else had had the same issue.

Thanks, Anand

Junio C Hamano· Dec 6, 2007, 05:51 UTC · re: Anand Kumria · lore

Re: When a merge turns into a conflict

Anand Kumria <wildfire@progsoc.org> writes:
> However when my colleague came to merge my patches in; git complained 
> that the file had conflict because:
>
> 	a. it found the ========= AsciiDoc header line

Perhaps .git/hooks/pre-commit hook is enabled for the person who needed to merge, fix conflicts and make a commit.

We ship the hook _disabled_ by default, but that hook inspects the change (relative to the HEAD, which means "difference this merge brings in relative to the state before I started the merge") and complains if it finds lines that:

 * have trailing whitespaces,
 * have a SP immediately before HT in the indentation, or
 * matches 7 or more <, >, or = at the beginning (i.e. <<<<<<<, =======,
   or >>>>>>>, typically are conflict markers).
And the last heuristics does trigger on an AsciiDoc text.

The easiest (and standard) workaround in such a case is, after inspecting the change yourself to make sure you are bitten by false positive, to commit with --no-verify option:

	git commit --no-verify
This bypasses the pre-commit hook.

← back to recent threads