Community
Participate
Working Groups
There should be Editor for .git* files I actually did so based on TextEditor https://github.com/Nodeclipse/org.nodeclipse.gitaddon (and ready to donate that, it is simple solution) But I think that the Editor should be based on Properties Editor. https://bugs.eclipse.org/bugs/show_bug.cgi?id=476420 Possibly there are better ideas. This is also related to Bug 342372 - support gitattributes
(In reply to Paul Verest from comment #0) > There should be Editor for .git* files > I actually did so based on TextEditor > https://github.com/Nodeclipse/org.nodeclipse.gitaddon > (and ready to donate that, it is simple solution) good idea, please contribute this simple solution as a first step https://wiki.eclipse.org/EGit/Contributor_Guide > But I think that the Editor should be based on Properties Editor. > https://bugs.eclipse.org/bugs/show_bug.cgi?id=476420 would be nice to use a smarter Editor, we should try to not add big dependencies, EGit should work in all Eclipse distributions. > Possibly there are better ideas. > > This is also related to Bug 342372 - support gitattributes
Also editor for gitconfig? Current table-based approach is not that user friendly IMHO. Nodeclipse uses MIT license, I don't think it is compatible with EPL, but I'm not an expert. Unfortunately the license problems must be clarified upfront. @Matthias, do you know it? org.eclipse.jdt.internal.ui.propertiesfileeditor.PropertiesFileEditor is probably not a good choice since it requires jdt and jdt cannot be mandatory dependency to egit. So I would like to see as small dependencies as possible so that those editors could make into the standard egit.ui plugin, but on the other side, if there are good resons to have dependencies, why not create a separated plugin? If developing such an editor one choice would be to use xtext (it offers plenty features for domain languages), but this brings lot of dependencies (I think), therefore it would imply that the editors should go into a separate plugin, something like org.eclipse.egit.ui.editors.
(In reply to Andrey Loskutov from comment #2) > Also editor for gitconfig? Current table-based approach is not that user > friendly IMHO. > > Nodeclipse uses MIT license, I don't think it is compatible with EPL, but > I'm not an expert. Unfortunately the license problems must be clarified > upfront. @Matthias, do you know it? I hoped that the author of that small plugin.xml snippet could re-license this snippet under EDL otherwise we would need a CQ which seems overkill for 10 lines of xml. > org.eclipse.jdt.internal.ui.propertiesfileeditor.PropertiesFileEditor is > probably not a good choice since it requires jdt and jdt cannot be mandatory > dependency to egit. true, EGit should not depend on JDT > So I would like to see as small dependencies as possible so that those > editors could make into the standard egit.ui plugin, but on the other side, > if there are good resons to have dependencies, why not create a separated > plugin? I think it would be nice to have it in the o.e.egit.ui bundle > If developing such an editor one choice would be to use xtext (it offers > plenty features for domain languages), but this brings lot of dependencies > (I think), therefore it would imply that the editors should go into a > separate plugin, something like org.eclipse.egit.ui.editors. not sure how big such xtext runtime dependencies would be
(In reply to Andrey Loskutov from comment #2) > Also editor for gitconfig? Current table-based approach is not that user > friendly IMHO. That should be other ticket. > org.eclipse.jdt.internal.ui.propertiesfileeditor.PropertiesFileEditor is > probably not a good choice since it requires jdt and jdt cannot be mandatory > dependency to egit. Please vote/comment Bug 476420 - make Properties File Editor public and extendable
You can see change at https://github.com/eclipse/egit/pull/5 Do you need all of below? (I have once sign CLA, but I remember that I should agree per project for it to take effect) " Legal Paperwork Before your first contribution can be accepted, you need to electronically sign the Eclipse Foundation Contributor License Agreement (CLA). You only have to do this once, and it covers all Eclipse projects. The new process was discussed in bug 381105 and introduced on June 27, 2013. Minimally, all Git commits you contribute must have the following: A single line summary in the comment field, followed by a more detailed descriptive paragraph; Your credentials (email address) captured in the "Author" field; and A "Signed-off-by" entry with matching credentials in the comment. The "Signed-off-by" entry is required. By including this, you confirm that you are in compliance with the Certificate of Origin. "
(In reply to Paul Verest from comment #5) > You can see change at https://github.com/eclipse/egit/pull/5 we don't use github, please push the change to Gerrit as described in the contributor guide > Do you need all of below? (I have once sign CLA, but I remember that I > should agree per project for it to take effect) > > " > Legal Paperwork > Before your first contribution can be accepted, you need to electronically > sign the Eclipse Foundation Contributor License Agreement (CLA). You only > have to do this once, and it covers all Eclipse projects. The new process > was discussed in bug 381105 and introduced on June 27, 2013. > > Minimally, all Git commits you contribute must have the following: > > A single line summary in the comment field, followed by a more detailed > descriptive paragraph; > Your credentials (email address) captured in the "Author" field; and > A "Signed-off-by" entry with matching credentials in the comment. > The "Signed-off-by" entry is required. By including this, you confirm that > you are in compliance with the Certificate of Origin. > " yes, this is required for contributions. If you once have signed the CLA electronically this is valid for contributions to any Eclipse project, AFAIR you have to renew the CLA every 3 years. I can see from the green checkmark near to your comments on this bug that you have signed the CLA.
bug 476812 looks related
