Thanks for the reply. Seems like a reasonable suggestion that learning maven and git from the command line is a good way to go, even if you switch back to IDE plugins later on. Coming at both from an eclipse perspective -- when you move to the command line, the rationales/workflows behind both aren't abstracted by UIs and become a lot more clear.
Adn BTW, I like this git tutorial: http://progit.org/book/ d On 2/11/12, Koustubh Sinkar <[email protected]> wrote: > Hello everyone, > > It has been really interesting to read this conversation about your pain > from moving the openMRS version control system from svn to git. > > So before I proceed, a brief introduction of myself. I am a Web developer > (Ruby on Rails) and have been meaning to try out the OpenMRS for a some > time now but unable to do it due to lack of time. Anyways, the first > version control that I seriously ever used in my life was git. I had tried > svn before but it was only limited to svn co <url_to_svn_repo>. But the > organization that I currently work for used git (and we still use it) when > I joined them and I have been quite comfortable using it. Before I share > with you more about my git experience, let me answer the one query that > struck me out and which I think is worth answering. > > What do you do if your remote branch has moved ahead and you already have > made some local changes? > > You stash your local changes using > > $ git stash > > and then pull your remote branch > > $ git pull origin master > > and the just pop your stashed changes > > $ git stash pop > > > Now at this stage you might have conflicts or you might not have; depending > on the changes that have happened on your local branch and the remote repo. > You can resolve those conflicts easily as they are listed as merge > conflicts that git is itself not able to resolve. > > Before you move your svn repo to git setup please answer the following > questions to yourselves:- > > Q 1. Are you going to administer your git remote repo yourself or you going > for a hosted solution? > > There are excellent solutions for either way you want to go. If you are > yourselves going to administer the server where you host the remote repo > please consider using gitolite for administration purposes. It is an > excellent tool. > > If you are thinking for hosted solutions for git, you have > http://www.github.com (which is the most popular), you have > http://www.gitorious.org (the source code of gitorious is available so even > you can host gitorious on your own servers but then again someone will have > to maintain the gitorious app on it; ). Then there are also > http://code.google.com and http://www.bitbucket.org which offer git hosting. > > If you really want to enjoy and understand git, use it only from the > command line and avoid using the gui tools, atleast in the beginning. I am > a Linux user and it will be difficult for me to empathize with Window's > users and the problems they face; which can of course be solved by > switching to Linux. > > Here I list a few resources to ease your way from svn to git > > http://tom.preston-werner.com/2009/05/19/the-git-parable.html > > you can also search for the git community book and read it for advanced > techniques like git bisect and so on, so forth. > > I hope I have been of help and have helped dispel your doubts and fears > about using git. > > Regards, > Koustubh Sinkar > कौस्तुभ सिनकर <http://www.about.me/ksinkar> > > > On 11 February 2012 22:40, Mark Goodrich <[email protected]> wrote: > >> 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] >> > > _________________________________________ > > 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] > _________________________________________ 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]
