I'd say that I found Git slightly more complicated when it comes to mimicking svn functionality, but significantly more complicated when trying to do more complex operations. Of course, this is because Git allows you to do more, but it definitely should be noted that there will be learning curve, and that should be taken into account when deciding if/when we want to migrate the core code... even after I thought I understood conceptually how I was supposed to be using Git, I ran into some trouble.
One thing I wanted to do for the sprint was try the model Burke mentioned in a recent email where all developers wouldn't need to have push privilege to the master repo... but rather would make pull requests of the master repo. The sprint seemed like a great time to test this functionality out. But when I spent some time the weekend before the sprint trying to write up instructions on how to do this, I wasn't able to figure out the correct workflow exactly... I WAS able to create my own remote fork of the htmlformentry master branch, check that out, make changes, push the changes back up to Git, and then make a pull request to the htmlformentry master from my remote fork... but what I WASN'T able to do was to figure the right workflow for merging in any changes from the master repo before making my pull request. So I decided to pass on trying to having people do it that way and just gave people push access to the main repo because I didn't want to spend a lot of of the sprint working out Git issues with understandably frustrated developers and/or having to resolve a lot of merge issues myself. I'm sure this IS possible, but my point is we shouldn't assume that it is trivia to learn how to do... and if we do have a university call, it would probably be best led by someone other than me who can actually explain how to do it... :) Also, I will note that when I did run into conflicts, conflict resolution seemed pretty similar to conflict resolution with svn... i.e., I didn't notice any great improvement. And finally, the Egit plugin, while not horrible, did have a tendency to throw exceptions with non-helpful error messages at times. I tended to use a combination of Egit and the Windows Git GUI to work with Git, and used Git at the command line when I was trying to figure out more complex operations. Anyway, I don't know if that came off as negative. I'm certainly not anti-Git. If I was starting a new project, I'd most likely use Git over SVN, and would be up for moving OpenMRS core to Git. However, just wanted to point out that there will a learning curve and some bumps in the road, so we should consider the pain and the opportunity cost of migration vs. the benefits. Take care, Mark ________________________________________ From: [email protected] [[email protected]] On Behalf Of Darius Jazayeri [[email protected]] Sent: Friday, February 10, 2012 6:15 PM To: [email protected] Subject: Re: [OPENMRS-DEV] HTML Form Entry Sprint I found git to be slightly more complicated than svn, but this is the first time I've really used it, so that's to be expected. I didn't ever create a branch, or switch between branches, since the only big ticket I worked on was in a separate module. (And I'm sure that if I had I'd be singing Git's praises.) One nice thing is that it lets us avoid checking in the eclipse-specific project files, and keeping those local. I ran into an annoyance with the EGit plugin--the first time I did a push, I typed the wrong password, and it has remembered it ever since, and I couldn't figure out how to make it forget. So I haven't been able to push from eclipse. Instead I've been using the github osx app, which is quite nice. -Darius On Fri, Feb 10, 2012 at 2:14 PM, Mark Goodrich <[email protected]<mailto:[email protected]>> wrote: We have reached the end of the two-week HTML Form Entry sprint. First of all, I’d like to thank everyone for their hard work and participation… we made it though more tickets than I had anticipated, and I enjoyed collaborating with everybody. We have closed a total of 25 tickets over the past two weeks, and should be closing a few more in the coming week. To talk about next steps… we still have 8 “in progress” tickets and 4 in the “post-commit” stage. Some of these are on my plate, and I plan to continue working on them next week. For anybody who still is assigned to a ticket that is “In Progress”, please let me know if you think you’ll still be able to finish the ticket, and, if not, what work remains . For those of you awaiting the next release of the module, version 1.9, my target is to release it sometime near the end up of week of February 27th. The delay is because I’m going to be out of the office for significant parts of the next two weeks, and because I’d like our ace volunteer tester, Cordt Byrne, to do some testing further testing before release, and he is only in the office once a week. Also, if any of the developers would like to share their experience working with Git, that would be much appreciates as we debate whether we want to migrate OpenMRS core from subversion to Git. Thanks again everyone… Take care, Mark ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
