Understanding Git conflict cause

Question

We work with 3 "main" branches, dev, uat, and master. We then use "feature" branches for any new work, branching from master, then merging back dev, PR to uat, master.

During the PR to uat, one dev in particular, sees almost constant merge conflicts on generated CSS (we are using SASS and gulp).

Whilst this sounds unexpected, the diffs are quite surprising:

+<<<<<<< destination:ac815dd…
.strip--beta .card-feed {
  background: transparent;
}
+=======
+>>>>>>> source:b49e50b72ee…

or:

@media (min-width: 1024px) {
+<<<<<<< destination:ac815ddf3…
   .copy h1 {
Add a comment to this line
+=======
+  .copy > h1 {
+>>>>>>> source:b49e50b72…
     font-size: 34px;
     line-height: 48px;
   }

I don't understand why a simple removal, of a couple of lines, or just a > would cause a conflict.

Initially, we thought to look at line endings etc. but this is generated…

How would we investigate the cause? Does anyone know why this would be happening?

Why do you have generated css files in source control in the first place? They are build artifacts and do not belong there. — 1615903, Oct 24 '16 at 11:14
And that they are generated doesn't mean you have an issue with line endings. You could have different line ending configurations on different dev environments. You should use binary diff. — Thibault D., Oct 24 '16 at 11:23
I agree,very much, that the generated files don't belong. However, this is the result of build process that is, at this time, beyond my control :/ — mediaashley, Oct 24 '16 at 14:42
A plain (non-`diff3`-style) conflict loses the information about what was in the common ancestor that caused the conflict, so in some cases it is impossible to see *why* there was a conflict without seeing the base version. Setting `merge.conflictstyle` to `diff3` causes the merge to include the base version as well, which may provide enough information to identify the conflict. — torek, Oct 24 '16 at 15:20

AnoE · Accepted Answer · 2016-10-24T12:05:07.940

I guess you have reasons to add the generated CSS to git, so I'll ignore this issue here.

I don't understand why a simple removal, of a couple of lines, or just a > would cause a conflict.

But that is exactly what conflicts are. Git does not care how severe a change is. You can instruct it to ignore certain whitespace changes, but not to treat several linebreaks as one.

The 3-way merge of two commits A and B works like this:

Find common ancestor C.
Find the diffs between C and A.
Find the diffs between C and B.
Compare the two sets of diffs, not line-by-line but hunk-by-hunk. Any overlapping hunks where the overlapped lines are not equal (maybe after whitespace normalization) are, by definition, conflicts.

I guess the real question you have to solve is why, if everything else is the same, the generated CSS is different for this developer than another. Maybe he uses different (versions of) tools to generate that CSS, and the (version information of the) tools are outside the repository?

While we never got to the bottom of this, I suspect the issue was the developer… I'm marking this as correct as it gives a helpful explanation of a 3-way merge. — mediaashley, Oct 13 '17 at 08:08

Understanding Git conflict cause

1 Answers1