Anyone use GIT for version control??

We've got a team of five using GIT for our four player fantasy themed sports game Crystal Brawl.

We basically never merge, because GIT can't auto-merge our Construct 2 XML files. We have to go into each file and manually fix the merges. Even if someone who's made a previous commit hasn't even touched a file I modified, it will mark a conflict, a la..

<<<<<<< HEAD

               <comment>Fireball removal -- DISABLED FOR NOW</comment>

               <event-block disabled="1" sid="5652866043242749">

=======

               <comment>Fireball removal</comment>

               <event-block sid="5652866043242749">

f7d0a3d1032d5be374ad3e3d5e04e2f5ac71a847

Our git .ignore looks like...

*.uistate.xml

*.capx.backup

*.capx.backup1

Is anyone else using GIT successfully and actually modifying files at the same time, and not in series?

Thanks,

Jon

Nope!

I'm using Git on one of my small projects and Subversion on my larger one. I'm working only by myself and have run into this also. During a game jam I lost 40 minutes trying to roll back/merge some files to specific version. I thought I had messed something when I just realized C2 didn't understand things.

I also spoke to a team of 2 at the local game dev meetup who also uses C2 and Git. Basically lamented they same fact. Even with a team of two and editing separate files C2 would easily get confused.

I've just learned to live with it as a team of one and know how to avoid problems now. Unfortunately this probably one of the biggest oversights with the engine/IDE. I do dread having a team of 2 or more though. I would LOVE to submit a bug report but how would you for something like this. :(

Did you guys follow the tutorial? I've been planning on using something like this for my next project but now I'm not so sure..

No, I didn't follow the tutorial. I have a I've had a personal LAMP+svn server for the past 2 years and help manage 3 different VCS at my day job so I'm pretty familiar with them. I also just setup a gitlab server for Git. :D

I quickly scanned the tutorial and didn't see anything out of the ordinary to take into consideration. But I did see that the user "CriticalBit" indicates in the comments he or she has had the same problem too! I forgot to mention I always use C2 as a folder when I use a VCS.

Other than that the tutorial looks great for new VCS users! Thanks!

JonStokes - the example you give shows that somebody has modified something. You do need to co-ordinate carefully to make sure two people don't modify the same thing before merging.

Ashley - Shouldn't modifying the same file only at (or around) the same line cause a conflict? That's my experience with Objective-C. It seems like in this case, modifying the same file anywhere will cause a conflict.   Even still, I'm fairly certain no one even modified the file in question, the stuff below the ======== was simply the previous state of the file, but I may be mistaken.

Is there any tool you all use that can out-merge git's auto merge? Is SVN actually better at this? I've never used SVN, but I just assume GIT is just as good at handling this stuff.

JonStokes - your code snippet does show that two people changed the same thing.

Ashley It appears to be in this case but I've seen issues arise from changes that should have no effect on each other.

If I'm able to reproduce the scenario in a public github repo. Have you fork then perform the merge and view the results would you be able to accept that in a bug report?

I fully understand the limitations of using a VCS and never expect them to take 100% responsibility of merging but they are designed to cover a lot of situations. My big problem is there is either a bug/oversight in the way C2 handles its files that make it difficult to coordinate/merge or there are some limitations -that aren't exactly the same when editing code files- that can be mentioned in the documentation and referenced whenever this problem arises in the future.

Just would love to see C2 fully integrated into my continuous integration system. ;) just needs some automation parameters to build from a CLI. Thanks!

I am pretty sure this is not Construct 2's fault. I'm not an expert on Git myself, but if it's anything like SVN, simply forgetting to update before you start working then trying to commit at the end will cause things you have not changed to conflict with things other people have changed, because your copy is out of date (and it doesn't know if your intent is to roll it back). So accidents or misuse of source control systems cause that type of error.

Thank ya kindly for your followup Ashely and BP.

Ashley - you said, "simply forgetting to update before you start working then trying to commit at the end will cause things you have not changed to conflict with things other people have changed, because your copy is out of date (and it doesn't know if your intent is to roll it back). So accidents or misuse of source control systems cause that type of error."

So even with SVN, you never work in parallel with others with Construct 2? You always let them finish, commit their changes, you check them out, you commit, and then they can go again? If so, this was my chief misunderstanding, and it may warrant more clarification in the SVN tutorial. I consider the main benefit of SCM to be intelligent merging, so we can all sit down and work together at the same time, and then merge our work, without having to fix a bunch of conflicts.

I work with XML files all the time for iOS development, and git will merge multiple concurrent updates to the same file with ease. I guess thats why I'm confused its causing problems in this case.

Just picking nits of course, Construct 2 is awesome and I'm glad I'm alive to witness its coming global domination.

No, the pattern (as described in the tutorial I linked to) is just to update, make changes, commit (for SVN anyway). It should only conflict if two people change the same thing at the same time (between update and commit). Normally working in parallel is fine, but you should have some level of co-ordination to try to avoid two people modifying the same thing at once.