Community
Participate
Working Groups
In order to deprecate old VCS in favour of git (bug 270854), adequate tooling should be available. This bug is created to track that.
We, as a community, need to provide a reasonable definition of "adequate".
I'm marking this as a blocker of setting up a git repo at Eclipse. I think a commitment to include git tooling as part of the SDK, or at the very least part of the EPP packages and/or Helios update site should be made in order for us to consider git as an official Eclipse repo.
(In reply to comment #1) > We, as a community, need to provide a reasonable definition of "adequate". I think that some really basic use cases must be supported. * Checkout from remote repo into local workspace * Share from local workspace into a remote repo * Commit from local workspace to remote repo * Update/Synchronize from remote repo to local workspace * create/update tags in remote repo * create branches in remote repo * switch local workspace to remote branch or tag Al of this should be possible without ever going to the command line.
(In reply to comment #3) > I think that some really basic use cases must be supported. Ping me when I can make patches from the EGit client instead of the CLI (see bug 297636). :)
(In reply to comment #4) > (In reply to comment #3) > > I think that some really basic use cases must be supported. > > Ping me when I can make patches from the EGit client instead of the CLI (see > bug 297636). :) My current assumption was that we would simply 'commit' to Gerrit instead of creating patches. But yes, we can add that to the list.
BTW, should we add the actual feature requests logged against EGit to the "Depends on" list?
Related, I also think we should remove this as a blocker to bug 257706. We're already providing git repos for new projects, and we shouldn't let the Egit client be a blocker to providing git repos to the general project space. Wayne, do you agree?
(In reply to comment #7) > Related, I also think we should remove this as a blocker to bug 257706. We're > already providing git repos for new projects, and we shouldn't let the Egit > client be a blocker to providing git repos to the general project space. > > Wayne, do you agree? Nope. I regard Bug 257706 as the "master" git bug. Closing 257706 will be a declaration of victory; a statement that Git is now 100% first-class at eclipse.org. This means, that there is first-class tooling in the workbench, support on Dash, etc. I recommend that we leave this bug as a blocker. I would like to somehow relate this bug to EGit, but I don't think that we can reasonably make an explicit connection. It's more correct, I believe, that we will close this bug when there is consensus that the quality is right, not any quantitative assessment that the right number of bugs have been closed. @Remy, it'd be great if you can check in with the EGit project once-in-a-while. Your direct input into the project will be very helpful.
Since EGit 0.9.3 is out now, are we "adequate" enough? Can we at least start transitioning some pieces like the website infrastructure at Eclipse to Git?
(In reply to comment #9) > Since EGit 0.9.3 is out now, are we "adequate" enough? > > Can we at least start transitioning some pieces like the website infrastructure > at Eclipse to Git? Have all of Gunnar's criteria from Comment 3 met? I'm not sure if we ever came to consensus on what "adequate" means. This sounds like something that we really need to bring to the community for a vote. What do we do in the event that somebody pushes back hard? There is also a resourcing issue. Denis, do you have any sense for what kind of effort this will take to change over?
(In reply to comment #10) > (In reply to comment #9) > > Since EGit 0.9.3 is out now, are we "adequate" enough? > > > > Can we at least start transitioning some pieces like the website infrastructure > > at Eclipse to Git? > > Have all of Gunnar's criteria from Comment 3 met? Yes, imho.
(In reply to comment #3) > * Checkout from remote repo into local workspace Works. > * Share from local workspace into a remote repo Works partially. Don't think you can share into *existing* remote repo as sub-folder. But I haven't expressed that in the initial requirement. ;) > * Commit from local workspace to remote repo Will never work. You always commit to local and push then to remote. > * Update/Synchronize from remote repo to local workspace Doesn't work. EGit has "Fetch From..." and "Merge...". If I do a "Fetch From..." something is updated but the files in my Eclipse project are still old. If I do a "Fetch From..." again, I get a message all up-to-date but the files in my Eclipse project are still not up-to-date. If I do a "Merge..." I get an error: > JGitInternalException: Exception caught during execution of merge command. > CheckoutConflictException: Checkout conflict with files: > hello.android/gen/hello/android/R.java Funny thing is, "hello.android" is not the Eclipse project I wanted to merge. It's in the repo too but I don't want to merge it. Synchronize doesn't work either. What's available is some preliminary support for the Synchronize View but no actual Synchronize operation. It has a "Merge All Non-Conflicting Changes" button. But after clicking that my working copy had modifications all over the place. Not sure if that is really intended. It seems that the complement of "CVS->Update" doesn't exist in EGit. > * create/update tags in remote repo Seems to work. From my understanding, I have to tag locally and then push. > * create branches in remote repo Seems to work. From my understanding, I have to branch locally and then push. > * switch local workspace to remote branch or tag Seems to work. From my understanding I have to fetch the branch and then switch locally. > Al of this should be possible without ever going to the command line. I tried but at least the simple "CVS/Update" command doesn't seem to work without command line (assuming that Git Rebase == CVS Update).
I opend/linked relevant EGit bugs in order to have a better visibility/tracking of what's missing.
What else is needed before we can close this nebulous bug? All the dependencies are fixed and closed. EGit/JGit have both graduated. Eclipse is on its way to Git adoption... http://eclipse.org/projects/scmcountdown.php Thoughts?
over 50% of the projects are on git...so can we close this issue and open specific targeted issues from here on out?
Yes it doesn't make sense for this bug to be open anymore. EGit has been in the release train since Indigo (June 2011) and provides adequate git tools.
(In reply to comment #16) > Yes it doesn't make sense for this bug to be open anymore. EGit has been in the > release train since Indigo (June 2011) and provides adequate git tools. +1
Closing as fixed.. Thanks for confirming.
