23

I'm wondering whether the merge=union option in .gitattributes makes sense for .pbxproj files.

The manpage states for this option:

Run 3-way file level merge for text files, but take lines from both versions, instead of leaving conflict markers. This tends to leave the added lines in the resulting file in random order and the user should verify the result.

Normally, this should be fine for the 90% case of adding files to the project. Does anybody have experience with this?

sehe
  • 374,641
  • 47
  • 450
  • 633
Ortwin Gentz
  • 52,648
  • 24
  • 135
  • 213
  • Hey Ortwin, did you end up trying this and if so, what is your experience? – Dick Jan 11 '12 at 05:04
  • Dick, I went for manual merging but in 90% of the cases I end up adding both sides. Using a graphical git client like Tower this manual merging isn't a big deal so this works great for me. – Ortwin Gentz Jan 12 '12 at 08:25
  • We used [`mergepbx`](https://github.com/simonwagner/mergepbx) as merge driver happily for several years, too bad it is no longer maintained. – fabb Jun 03 '22 at 17:30

2 Answers2

19

Not a direct experience, but:

  • This SO question really advices again merging .pbxproj files.

The pbxproj file isn't really human mergable.
While it is plain ASCII text, it's a form of JSON. Essentially you want to treat it as a binary file.

(hence a gitignore solution)

Actually, Peter Hosey adds in the comment:

It's a property list, not JSON. Same ideas, different syntax.

The truth is that it's way more harmful to disallow merging of that .pbxproj file than it is helpful.
The .pbxproj file is simply JSON (similar to XML). From experience, just about the ONLY merge conflict you were ever get is if two people have added files at the same time. The solution in 99% of the merge conflict cases is to keep both sides of the merge.

So a merge 'union' (with a gitattributes merge directive) makes sense, but do some test to see if it does the same thing than the script mentioned in the last question.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    It's a property list, not JSON. Same ideas, different syntax. http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/PropertyLists/ – Peter Hosey Apr 28 '10 at 17:15
  • I just came across this question and answer. It sure seems like a good idea, I can't think of where entries interspersed randomly would mess with anything. Does anyone have experience trying this? – Kendall Helmstetter Gelner May 31 '12 at 22:42
  • @PeterHosey is right, here is more information about the topic http://en.wikipedia.org/wiki/Property_list – Emil Marashliev Oct 11 '12 at 09:24
  • @EmilMarashliev good point, I have aded the link to the answer. – VonC Oct 11 '12 at 09:39
  • 2
    We (a Team of 3) tried this configuration for about 2 months and worked fine until recently we had a bunch remove and add files. The pbxproj failed all the time ever since. As a result, we decide to merge manually again. – james sa Dec 13 '12 at 03:42
16

I have been working with a large team lately and tried *.pbxproj merge=union, but ultimately had to remove it.

The problem was that braces would become out of place on a regular basis, which made the files unreadable. It is true that tho does work most of the time - but fails maybe 1 out of 4 times.

We are back to using *.pbxproj -crlf -merge for now. This seems to be the best solution that is workable for us.

Corey Floyd
  • 25,929
  • 31
  • 126
  • 154
  • I've had the same experience as Corey. For us it occurred when two developers added a Group on different branches. The project file handles the Group sorting in an odd fashion which makes merge=union not work correctly in this case. For us, the downside when this fails outweigh the benefits when it succeeds. Once you're used to merging both the left and right side changes in the project file, it's not too bad. – hustoj2 Feb 07 '14 at 19:41