That last non-sensical sentence should read "...you can use EGit *and* the command line tools *without* passwords..."
On 16 November 2011 08:59, Rowan Seymour <[email protected]> wrote: > I think the URL should be > https://github.com/OpenMRS/openmrs-module-htmlformentry*.git* > * > * > Have you configured keys for use with github? If you do that then you can > use EGit the command line tools passwords (https://github.com/account/ssh) > > > On 15 November 2011 20:23, Mark Goodrich <[email protected]> wrote: > >> Fwiw I have been able to clone the htmlformentry project with Git GUI, >> but when I try to import htmlformentry with EGit I get the following error: >> **** >> >> ** ** >> >> Steps to reproduce:**** >> >> **1) **Eclipse->File->Import…**** >> >> **2) **Select Git->Projects from Git**** >> >> **3) **Select “Clone”**** >> >> **4) **Set “URL” to >> https://github.com/OpenMRS/openmrs-module-htmlformentry**** >> >> **5) **Enter my Git username and password**** >> >> **6) **Click “Next”**** >> >> ** ** >> >> Get error message “Cannot list the available branches. Reason >> https://github.com/OpenMRS/openmrs-module-htmlformentry: >> https://github.com/OpenMRS/openmrs-module-htmlformentry/info/refs?service=git-upload-packnot >> found. >> **** >> >> ** ** >> >> Anyone know what I am doing wrong here?**** >> >> ** ** >> >> Thanks,**** >> >> Mark**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> **** >> >> ** ** >> >> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Rowan >> Seymour >> *Sent:* Tuesday, November 15, 2011 5:15 AM >> >> *To:* [email protected] >> *Subject:* Re: [OPENMRS-DEV] FW: HTML form entry changes**** >> >> ** ** >> >> I've added some information on tools for using Git. I've been trying EGit >> and the Maven SCM connector for Git. The Maven SCM connector doesn't create >> a project that EGit recognizes and I haven't yet figured out how to make it >> managed by EGit afterwards. EGit let's you clone a repository based on it's >> URL and then afterwards you can easily import that as a Maven project.*** >> * >> >> ** ** >> >> I also tried NetBeans and IntelliJ IDEA. NetBeans has an easy to install >> plugin for Git and IntelliJ IDEA comes with built-in support for Git and >> GitHub.**** >> >> ** ** >> >> I think I still prefer the command line but EGit seems pretty good, and >> there's always the GitHub app for Mac OSX.**** >> >> On 15 November 2011 10:24, Rowan Seymour <[email protected]> wrote:* >> *** >> >> Thanks Kishore **** >> >> ** ** >> >> Is there any way we can securely manage a shared authors.txt file for >> mapping SVN accounts to Github accounts? Running a script on the SVN repo >> can get a list of usernames but that doesn't tell someone what email >> addresses are being used on Github.**** >> >> ** ** >> >> Do we envisage people migrating their own modules or someone doing this >> on their behalf?**** >> >> ** ** >> >> On 14 November 2011 21:34, Yekkanti Kishore Kumar < >> [email protected]> wrote:**** >> >> Added some basic scripts and guidelines to migrate the repo form svn to >> git at https://wiki.openmrs.org/display/docs/Migrating+to+Git**** >> >> ** ** >> >> On Fri, Nov 11, 2011 at 1:35 PM, Rowan Seymour <[email protected]> >> wrote:**** >> >> Before Git fans start migrating all their modules... it'd be great to get >> some more information onto >> https://wiki.openmrs.org/display/docs/Migrating+to+Git so that we can >> all be consistent. Also it'd would be good that people doing migrations >> have access to a single authors.txt account mapping file which we can all >> add to, though obviously this contains people's email addresses so we don't >> want to make that too public.**** >> >> ** ** >> >> It also seems like mavenization would be sensible first step before >> git-ization, so it would be great if someone could fix the mavenization >> scripts so they work with the agreed omod/api project layout, and a few >> other problems I've noticed. Shall I open a ticket for this?**** >> >> ** ** >> >> @Kishore can you add some info to >> https://wiki.openmrs.org/display/docs/Migrating+to+Git about which >> scripts you used for the conversion of htmlformentry?**** >> >> ** ** >> >> On 11 November 2011 00:16, Darius Jazayeri <[email protected]> >> wrote:**** >> >> I was originally skeptical of Burke's "just give everyone access, and >> deal with issues if they become a problem" viewpoint. But it's grown on me. >> **** >> >> ** ** >> >> I think it'd be fair and good if the default JIRA setup for projects that >> we host on OpenMRS JIRA is that all OpenMRS committers can assess tickets. >> The module owner gets an email about this anyway. And I think it's fine to >> let a module owner opt-out of this if they're going to be more proactive, >> and want more control.**** >> >> ** ** >> >> -Darius**** >> >> ** ** >> >> On Thu, Nov 10, 2011 at 12:41 PM, Michael Seaton <[email protected]> wrote: >> **** >> >> Hi Michael, >> >> Thanks, I understand your position. What I'm saying is that I _did_ >> observe a bug before and I _was_ able to fix it, but the owner of the >> module was out of contact for a period of time and without asking Darius to >> add me as an approver, I was unable to move that ticket forward. >> >> I'm not saying that there aren't points pro and con here. But I would >> like to get the community's input on this, and if the consensus is to let >> the community police itself and not add process restrictions unnecessarily, >> then I would hope that we're open to changing the way things operate. >> >> Regards, >> Mike**** >> >> >> >> >> >> On 11/10/2011 03:25 PM, Michael Downey wrote: **** >> >> Hi Mike,**** >> >> On Thursday, November 10, 2011 at 3:01 PM, Michael Seaton wrote:**** >> >> 1. I could check out the module code, reproduce the error, commit a fix >> back to trunk of the module >> 2. I could create a ticket to report this particular issue >> 3. I could _not_ mark this ticket as "Ready For Work", "Claim Issue", or >> "Assign Issue". That seems restricted. >> 4. Because of 3, I could also not perform "Committed Code" on the issue** >> ** >> >> That sounds more likely -- I think a fundamental assumption is that the >> critical path for issue management is that bugs are generally observed (and >> reported) before they are fixed. It's good for communication and it's good >> change management.**** >> >> ** ** >> >> For OpenMRS core, I personally would be concerned with allowing everyone >> to do issue triage due to potential quality and release planning issues. Of >> course, there is inherent delay in such a model as it scales - see >> Mozilla's challenges with triage [0] for example. On the other hand, a >> module developer or may choose otherwise (which is fine, of course) and can >> add multiple individuals or indeed all JIRA users into the "Approver" role >> which can triage issues. Fortunately, JIRA like GitHub has decentralized >> administration which allows this flexibility and independence, which I >> agree is important for a large distributed project like OpenMRS.**** >> >> ** ** >> >> Regarding the example at hand, I notice you are listed as in the Approver >> role for this project - I assume that's a recent addition and you'd be able >> to triage tickets for this project in the future.**** >> >> ** ** >> >> Michael**** >> >> ** ** >> >> [0] >> http://tylerdowner.wordpress.com/2011/08/27/some-clarification-and-musings/ >> **** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> >> ** ** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> >> >> >> **** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> >> >> >> **** >> >> ** ** >> >> -- >> Regards, >> Kishore Kumar Yekkanti.**** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> >> >> >> **** >> >> ** ** >> >> -- >> *Rowan Seymour* >> tel: +250 783835665 >> http://twitter.com/rowanseymour**** >> >> >> >> **** >> >> ** ** >> >> -- >> *Rowan Seymour* >> tel: +250 783835665 >> http://twitter.com/rowanseymour**** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > > > -- > *Rowan Seymour* > tel: +250 783835665 > http://twitter.com/rowanseymour > > -- *Rowan Seymour* tel: +250 783835665 http://twitter.com/rowanseymour _________________________________________ 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]
