VS 2013 C# and Git: .csproj files don't merge upon pulling -

me , friend working on project written in c# using vs 2013 express git (not vs git plugin, mind you), , we're running problem. our workflow setup this: have central repository, , each have our own fork of repository work on separately. when our individual work done push central repository. when want sync central repository, pull.

the problem when pull, csproj files randomly update. update , files have been added since last pull show in vs, , other times csproj file unaffected.

it's strange because csproj gets updated everywhere else, including central repository, doesn't update when pull.

in our .gitattributes file have .csproj set merge=union.

the command perform when pulling git pull upstream upstream remote pointing our central repository.

any ideas?

i'll put in answer, based on edward thomson's comment, contains link merge conflicts in csproj files (haacked.com/archive/2014/04/16/csproj-merge-conflicts). please note know nothing visual studios, c#, or windows, know git. :-)

the problem when pull, csproj files randomly update. update , files have been added since last pull show in vs, , other times csproj file unaffected.

first, let's few brief review notes:

1. git pull git fetch followed git merge. can tell git rebase instead. may idea depending on development flow, won't change particular problem, because ...
2. nothing else in git makes merge commits, ...
3. several other commands, including git rebase, use merge machinery.
4. pushing (git push) never merging, see problem in "get me new stuff after both , else did something" case. then, whether see problem depends quite heavily on , someone-else did. because merge machinery, used both git merge , git rebase, not smart.

now let's take @ underlying problem, (based on link) these *.csproj files contain xml: structured data git's built-in text-oriented merge operations cannot merge correctly.

changes conflict when, in git diff output, 2 different lines of development (the branches or commits being merged) made different changes same region of single file. 1 classic example occurs in files when 2 editors cannot agree on spelling. instance, made change time ago:

diff --git a/plates.tex b/plates.tex index 09939ca..3dfc610 100644 --- a/plates.tex +++ b/plates.tex @@ -15,7 +15,7 @@ took on trip parts of australia in february of 2010  \end{plate*}  kangaroo known marsupial.  there 4 species of large kangaroo: -the red, eastern , western gray, , antilopine. +the red, eastern , western grey, , antilopine.  there smaller tree-kangaroos , rat-kangaroos.   \begin{plate*}[h] 

if merge else made different change of lines shown in diff, left "grey" spelled letter a, conflict. instance, if editor insist word spelled “kangaru”, changes conflict:

auto-merging plates.tex conflict (content): merge conflict in plates.tex automatic merge failed; fix conflicts , commit result. 

when git encounters conflicting changes, usual reaction declare there conflict , stop. leaves work-tree version of file containing conflict markers <<<<<<< ======= >>>>>>> surrounding both sides of conflict (along ||||||| above base version if , if set merge.conflictstyle diff3):

\end{plate*} <<<<<<< head kangaru known marsupial. there 4 species of large kangaru: red, eastern , western gray, , antilopine. there smaller tree-kangarus , rat-kangarus. ||||||| merged common ancestors kangaroo known marsupial. there 4 species of large kangaroo: red, eastern , western gray, , antilopine. there smaller tree-kangaroos , rat-kangaroos. ======= kangaroo known marsupial. there 4 species of large kangaroo: red, eastern , western grey, , antilopine. there smaller tree-kangaroos , rat-kangaroos. >>>>>>> master  \begin{plate*}[h] 

again, though, default behavior. can, through command line switches or .gitattributes file, change default.

you selected union merge, , the git documentation has been improved bit:

union

run 3-way file level merge text files, take lines both versions, instead of leaving conflict markers. tends leave added lines in resulting file in random order , the user should verify result. not use if not understand implications.

(boldface mine). short version here, though, git believe merge succeeded (well, did succeed) producing invalid xml file. there examples on linked haacked.com page of how goes wrong *.csproj files, true of union merge: it's not smart enough right result , there few places reasonable driver. make sense invoke manually in cases, review file , make fixups hand, since succeeds , lets merge proceed, must careful putting in .gitattributes.

ideally, have merge driver understood xml formatting and intent of .csproj file (xml formatting alone not sufficient semantics of markup not tied syntax). since not use vs on windows, can quote haacked.com article again:

another way write proper xml merge driver git, that’s quite challenge co-worker markus olsson can attest to. if easy, or moderately hard, have been done already. though wonder if limited common .csproj issues write 1 isn’t perfect enough handle common merge conflicts? perhaps.

if contents simple example xml, think such driver not difficult, suspect more complicated.