Community
Participate
Working Groups
I request the support for git svn support to commands like: git svn clone git svn rebase git svn dcommit git svn branch git svn tag Follow some suggestion: On a git-svn project it should raise a warning if the user try to rebase an already dcommitted (on subversion branch) commit. see https://git.wiki.kernel.org/index.php/SvnMigration and this discussion on the git mailing list http://marc.info/?l=git&m=127445374518553&w=2 I think this would help a lot java developers willing to switch to git. Moving to git-svn before "pure" git would be easier then moving directly to git.
This looks like a good idea however it's not on our radar at the moment. It would be great if someone wanted to step up in the community to implement this. Our focus at the moment is solid Eclipse and Git integration as Eclipse.org is moving to Git for all of its project so understandably this is where a lot of our focus is going.
Would like to see this implemented too, but don't have cycles free to dedicate to developing it. Yet. However, if you want a whole bunch of new people using eGit instead of Subclipse/Subversive, having tooling to ease transition would certainly help.
Unfortunately, my development experience with the Eclipse IDE is very limited, so I can't really help develop this feature, but I can see where a lot of people with old SVN repos would benefit from the capability. Where I work, it's not feasible to convert all of our old SVN repos to git, but using git is certainly beneficial to the developers.
Might be something for 4.3 release plans?
This sure would be nice, especially for groups planning a transition from svn to git.
(In reply to comment #1) > This looks like a good idea however it's not on our radar at the moment. > > It would be great if someone wanted to step up in the community to implement > this. Our focus at the moment is solid Eclipse and Git integration as > Eclipse.org is moving to Git for all of its project so understandably this > is where a lot of our focus is going. Would someone with a good knowledge of both Git and Eclipse be ready to act as a mentor?
If this is not on the radar for EGit, what is? I would like to understand the priorities in your product backlog (or whatever you call it). I think that in many corporate environments teams are transitioning from SVN to Git (and also in Eclipse foundation), so it would make sense to support them with proper IDE tooling. This would also be a chance to positively differentiate Eclipse from other IDEs on the market, kind of a "unique selling point".
(In reply to Jochen Wiedmann from comment #6) > (In reply to comment #1) > > This looks like a good idea however it's not on our radar at the moment. > > > > It would be great if someone wanted to step up in the community to implement > > this. Our focus at the moment is solid Eclipse and Git integration as > > Eclipse.org is moving to Git for all of its project so understandably this > > is where a lot of our focus is going. > > Would someone with a good knowledge of both Git and Eclipse be ready to act > as a mentor? Repeating my question: Any mentors available?
(In reply to Jochen Wiedmann from comment #8) > Repeating my question: Any mentors available? We would certainly help with any questions on the mailing list and review patches. To set up a development environment for starting to work on this, see our contributor guide: https://wiki.eclipse.org/EGit/Contributor_Guide Here is my personal opinion how this should be done: For implementing the "git svn *" commands, I would use Runtime.exec instead of reimplementing them in Java. That would mean that native Git has to be installed for the commands, but I really don't think porting the Perl scripts to Java is something anybody wants to do. For integrating it into Eclipse, the following would have to be implemented in a new optional EGit feature (that can be separately installed): - Add an extension of org.eclipse.ui.importWizards for having a "Projects from git-svn" import wizard. This would call "git svn clone ..." and then import the projects. - In case a repository uses git-svn (which can be detected), show some additional menu entries and toolbar buttons, e.g. for "git svn rebase" and "git svn dcommit". "git svn branch" and "git svn tag" would probably need dialogs/wizards. - For specifying the path to git, a new preference page may also be necessary.
If this is going to be a separate feature using native git is there any integration with EGit you are envisioning ? What are the IP / license implications of using native Git (GPL) from EGit (EPL) ?
(In reply to Matthias Sohn from comment #10) > If this is going to be a separate feature using native git is there any > integration with EGit you are envisioning ? The idea would be that the new feature only executes the "git svn" commands and depends on EGit for the things that are the same. The new feature would probably need to contribute additional items to the team menu and Git toolbar. In case you're not familiar with how git-svn works, see [1] for a typical workflow. The repository is a normal Git repository with some additional metadata in the config and the commit messages. [1] http://rapaul.com/2010/01/13/my-git-svn-workflow/ > What are the IP / license implications of using native Git (GPL) from EGit > (EPL) ? Just executing a binary does not have any license implications AFAIK (but IANAL). See bug 107436 for an example of this in the platform.
(In reply to Robin Stocker from comment #11) > (In reply to Matthias Sohn from comment #10) > > If this is going to be a separate feature using native git is there any > > integration with EGit you are envisioning ? > > The idea would be that the new feature only executes the "git svn" commands > and depends on EGit for the things that are the same. The new feature would > probably need to contribute additional items to the team menu and Git > toolbar. yeah, all that should come in its own feature, so that only those who use git-svn install it. > In case you're not familiar with how git-svn works, see [1] for a typical > workflow. The repository is a normal Git repository with some additional > metadata in the config and the commit messages. > > [1] http://rapaul.com/2010/01/13/my-git-svn-workflow/ > > > What are the IP / license implications of using native Git (GPL) from EGit > > (EPL) ? > > Just executing a binary does not have any license implications AFAIK (but > IANAL). See bug 107436 for an example of this in the platform. IANAL either, so I'd suggest to file a CQ upfront in order to clarify this question
(In reply to Matthias Sohn from comment #12) > IANAL either, so I'd suggest to file a CQ upfront in order to clarify this > question I started the wizard on the portal for a CQ, but it wants to know all kinds of irrelevant information. Is there a way to do this without jumping through hoops?
(In reply to Robin Stocker from comment #13) > (In reply to Matthias Sohn from comment #12) > > IANAL either, so I'd suggest to file a CQ upfront in order to clarify this > > question > > I started the wizard on the portal for a CQ, but it wants to know all kinds > of irrelevant information. Is there a way to do this without jumping through > hoops? than I'd ask technology-pmc or Wayne to give advice how to clarify this question
Ok, so calling "git svn" has been approved, see mailing list thread and CQ: https://dev.eclipse.org/mhonarc/lists/technology-pmc/msg05165.html https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7730 So if anyone wants to start working on this, I don't think there's anything in the way anymore. See also comment 9.
Any progress on this feature ?
Was anything done to add this feature? I would like to contribute, so the question is: does it have to be started from scratch or I can help on some ongoing project?
(In reply to Grzegorz Pasieka from comment #17) > Was anything done to add this feature? I would like to contribute, so the > question is: does it have to be started from scratch or I can help on some > ongoing project? We also are very interested in this feature, and can potentially contribute if there is somewhere to get started.
Yes, it is 2017 and still there're svn repos out there. Let's start this journey! https://wiki.eclipse.org/EGit/Contributor_Guide Before read more docs I will try to run egit plugin and upload changes to https://github.com/albfan/egit See https://github.com/albfan/egit/issues/1
I suggest you upload changes to https://git.eclipse.org/r/egit/egit for review. Feel free to file more bugs here in bugzilla (use severity enhancement) if you think this helps to plan your work.
Matias, https://git.eclipse.org/r/egit/egit don't work for me. Is it moved to somewhere else?
(In reply to Alberto Alonso from comment #21) > Matias, https://git.eclipse.org/r/egit/egit don't work for me. Is it moved > to somewhere else? Did you try to clone from this URL ? That should work. See https://git.eclipse.org/r/#/admin/projects/egit/egit
I'm trying to build all eclipse rcp, but cannot make progress. https://twitter.com/albfanjul/status/960203086395576332 Is it not the right approach? I don't know how eclipse uses egit and want to debug the basic operations to understand the whole thing. Is in general hard to build eclipse rcp? I will try to hack directly on egit by now
There is no need to compile the complete Eclipse platform if you want to debug EGit. The easiest way to setup environment for debugging and patching JGit/EGit is to use the Oomph installation for hacking on JGit/EGit which is described in the contributor guide [1]. [1] https://wiki.eclipse.org/EGit/Contributor_Guide#Automated_Developer_Setup
Just activate the email notifications. Finally I learn the hard way eclipse RCP is not needed to hack on git plugin Installing de developer setup right now!
Supposed clone urls for jgit, egit and egit-github do not work I skipped those steps and do it manually from command line (looking at web interface): git clone http://git.eclipse.org/gitroot/jgit/jgit.git instead of git clone https://git.eclipse.org/r/jgit/jgit and so on The rest just works, and I can run as Eclipse application and debug on it Let's hack on this
(In reply to Alberto Alonso from comment #26) > Supposed clone urls for jgit, egit and egit-github do not work Normally they do, but yesterday there was a Gerrit outage.
Yes, gerrit url works again. I read the comments about use Runtime.exec, is that something approved? I can't see the CQ https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7730 (and what it clarifies) If that is the way to implement git-svn, is there any other plugin using Runtime.exec? (I suppose m2e is just a wrapper around mvn but didn't dig to much into his code. Any code tip here is appreciated: I want to use standardized operations to check for binary exists, configuration on preferences, version of binary, monitoring progress, error handling ... If there's no general advice I will try to implement something on my own and wait for a review.
(In reply to Alberto Alonso from comment #28) > Yes, gerrit url works again. > > I read the comments about use Runtime.exec, is that something approved? I > can't see the CQ https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7730 (and > what it clarifies) CQ 7730 approves that we are allowed to call native git if we don't bundle it, don't link against it and don't make it mandatory (so called "works with" approval). > If that is the way to implement git-svn, is there any other plugin using > Runtime.exec? (I suppose m2e is just a wrapper around mvn but didn't dig to > much into his code. Any code tip here is appreciated: I want to use > standardized operations to check for binary exists, configuration on > preferences, version of binary, monitoring progress, error handling ... > > If there's no general advice I will try to implement something on my own and > wait for a review. in jgit we have FS.runInShell() used to run filters and hooks
Almost done. Using FS.detect() is just the first part. This is still a wip: https://github.com/albfan/jgit/tree/git-svn (parsing a svn-remote) https://github.com/albfan/egit/tree/git-svn (adding a Fetch from bridged svn action) I'm struggling with UI (can't make my Actions being shown on contextual menus) Don't know if I can get review for a WIP on gerrit to ask about how to implement something. A good tutorial for UI changes for a plugin (contextual menus, dialogs, menus) will help a lot I miss a lot a channel on IRC for this: but freenode #eclipse-dev seems to be really quiet (and unavaliable on matrix.org while #eclipse is avaliable).
Yes, please develop this on Gerrit. We review and discuss changes there. Just had a quick (VERY quick) look at the two commits on github. Here's some preliminary assorted comments (yes, I realize it's WIP): * I have the feeling a lot of this is copy-paste from existing code, and that there are a lot of similarities between the original and the new copies. Please avoid duplicate code; it's a maintenance nightmare. Better refactor. For instance, if the existing fetch UI nearly does what would be needed for git svn fetch, then don't just copy all the related classes but refactor such that the new behavior can become a specialization of the common part. That may also involve touching the existing code, to make that a different specialization of the same common part. * Be careful not to introduce duplicate command accelerators. For instance, you chose "&Fetch from SVN", but there's already "&Fetch from Upstream". * You will need new icons (in SVG). Using the same icon for different commands is confusing to the end user. The icon for "Fetch from SVN" could perhaps be the fetch icon with some "svn" indication in the cloud. * Familiarize yourself with Eclipses command/handlers framework. For instance, plugin.xml in EGit UI is lacking a handler for the new command. Good tutorials do exist online, but even so it won't be easy if you've never done this before. * Adjust the copyright headers. * Please use descriptive and meaningful commit messages. (More than just one line.) Look at existing commits to get a feeling for this, and follow the EGit/JGit coding standards and commit message guidelines: http://wiki.eclipse.org/EGit/Contributor_Guide#Coding_standards While old code may not use {} braces always, we do require it for new code, including copied code. * You'll have to execute the git svn fetch inside the correct directory. * FS.detect().newInstance() is not necessary. Use FS.DETECTED, or repository.getFS(). Hope this gives you some initial hints. Note that this is all preliminary, and for a first WIP change, not all of it needs to be done right away. For instance, a new icon can be done at some later point. Looking forward to seeing changes on Gerrit.
Sure Thomas, I'm agree with all your comments. About copy/paste, which is plain to see, is just because a svn-remote is not exactly a remote, since it cannot push/pull but "svn fetch/svn dcommit" and was afraid to ruining the code mixing concepts. Let me rework all that and start committing to gerrit
So close! Fixed detection of svn-remote I'm dealing with UI steps. I guess I need to debug normal fetch operations to see what will work for "git svn fetch" I will keep pushing on github until I have all things Thomas point out in good shape, but don't want to loose the traction and show I'm still working on it
I did a try with jgit but none ssh keys or https access allows me to push a new branch with my changes To https://git.eclipse.org/r/a/jgit/jgit ! [remote rejected] git-svn -> git-svn (prohibited by Gerrit: create access denied for refs/heads/git-svn) have to read any doc about how to push on gerrit to get review?
Thank you for the hard work on this Alberto!
(In reply to Alberto Alonso from comment #34) > have to read any doc about how to push on gerrit to get review? Yes. Here are some links to get you started: * http://wiki.eclipse.org/EGit/Contributor_Guide#Contributing_Patches * http://wiki.eclipse.org/EGit/Contributor_Guide#Doing_Code_Reviews_with_Gerrit * http://wiki.eclipse.org/EGit/User_Guide#Working_with_Gerrit * http://www.vogella.com/tutorials/Gerrit/article.html#gerritreview_clonerepo Important point from the last one: with Gerrit, individual commits are reviewed. Changes are made by amending the commit and then pushing again. That's different from GitHub, where whole branches are reviewed in the form of pull requests.
nvm. I found I have an automated user created on gerrit. I have my hook for change-id now. Let's rework a couple of things and start first review!
Hi guys, is this still being developed?
Yes Chris. I need to start with the gerrit review process I think the part for jgit is ready, let me see if I can push that first
New Gerrit change created: https://git.eclipse.org/r/120496
