Home » Eclipse Projects » EGit / JGit » bisect(supporting bisect)
| |
| Re: bisect [message #1235978 is a reply to message #1234215] |
Sat, 25 January 2014 21:52   |
 R Shapiro
Messages: 386
Registered: June 2011 |
Senior Member |
|
|
I created a little plugin project on github to get some simple Eclipse integration for important Git features that will either never be part of JGit (like svn bridging) or might be eventually but aren't in the works (like bisect). The idea is trivial: add some menu/toolbar items that simply launch command-line Git with the right options.
At the moment it includes very early versions of the three core svn bridging operations : fetch, rebase, dcommit
The name of the github project is eclipse-git-extensions. Feel free to build it and try it but use with caution.
I'm a total newbie plugin developer, if anyone with more experience wants to volunteer to help improve this, that would be great.
If you're good at creating nice toolbar icons, that would be useful too. Currently the icons I use for svn fetch, rebase and dcommit are 'borrowed' from the EGit icons for fetch, pull and push, respectively, which is of course a little confusing. When I add some bisect operations (start, good, bad, reset) I'll be at complete loss for icons.
|
|
|
| Re: bisect [message #1269229 is a reply to message #1235978] |
Tue, 11 March 2014 15:10 |
R Shapiro
Messages: 386
Registered: June 2011 |
Senior Member |
|
|
If anyone cares, the plugin I've been working on now supports quite a few useful Git features not currently available via EGit, and it finally has an update site: http://home.comcast.net/~reshapiro/org.res.gitx/
Features: SVN bridging; bisect; bundle files (create, fetch, pull); diff-stat between any two references; list commits in one ref but another; creating light-weight tags; pruning obsolete remote refs; listing orphan commits.
It also includes command-line Git versions of fetch, pull, push and checkout, since with large data these can be significantly faster than with JGit. The fetch and pull also have a prune option. I threw in 'git status' as well, sometimes it helps correct anomalies in Egit's view of what's changed.
Coming soon: Checkout of a path; merge strategies
The gui widgets are sub-optimal - I know Swing and AWT but not SWT. If a SWT expert wants to help clean these up, let me know. Otherwise it seems to work pretty well, at least in unix. It hasn't been tested in Windows yet.
I would love to get this integrated with EGit somehow but as a relative novice at plugin development I wouldn't know where to begin. For now the only integration is that this plugin makes use of some EGIt variables, so it knows which repository is currently selected and where the corresponding .git directory lives.
|
|
|
| Re: bisect [message #1270949 is a reply to message #1269229] |
Thu, 13 March 2014 22:56 |
Robin Rosenberg
Messages: 332
Registered: July 2009 |
Senior Member |
|
|
R Shapiro skrev 2014-03-11 16.10:
> If anyone cares, the plugin I've been working on now supports quite a few useful Git features not currently available via EGit, and it finally has an update site:
> http://home.comcast.net/~reshapiro/org.res.gitx/
403 ?
> Features: SVN bridging; bisect; bundle files (create, fetch, pull); diff-stat between any two references; list commits in one ref but another; creating light-weight
> tags; pruning obsolete remote refs; listing orphan commits.
>
> It also includes command-line Git versions of fetch, pull, push and checkout, since with large data these can be significantly faster than with JGit. The fetch and pull
> also have a prune option. I threw in 'git status' as well, sometimes it helps correct anomalies in Egit's view of what's changed.
> Coming soon: Checkout of a path; merge strategies
I don't think creating yet another plugin helps us.
>
> The gui widgets are sub-optimal - I know Swing and AWT but not SWT. If a SWT expert wants to help clean these up, let me know. Otherwise it seems to work pretty well, at
> least in unix. It hasn't been tested in Windows yet.
>
>
> I would love to get this integrated with EGit somehow but as a relative novice at plugin development I wouldn't know where to begin. For now the only integration is that
> this plugin makes use of some EGIt variables, so it knows which repository is currently selected and where the corresponding .git directory lives.
EGit will not be made dependent on Git for licensing reasons so those part are out of the question. There are already other plugins that use the CLI, and may therefore have
better compatibility with Git.
As for differences in status between Git and EGit, that's a matter of bugs and to some extent that C Git store more stat info in the index than JGit does. C Git can be
configured to only look at the same stat fields as JGit does. As for the bugs, Alex Richard have identified some bugs. See https://git.eclipse.org/r/#/c/22160/ for failing
unit tests that illustrate bugs.
To add new features you need to understand that EGit knows little oabout Git. Most of the Git stuff is in JGit, which is not dependent on the Eclipse plugin mechanisms,
though the code is availables as either plain jars or OSGi bundles (extra stuff the MANIFEST.MF makes the jar a bundle). Adding new capabilities like e.g. bisect requires
no Eclipse knowledge. You do need to understand how bisect works in and out (or learn) since we will not use the C Git code. You need to write unit tests for your code,
or we won't accept it. You can still ask for comments on ideas without unit tests, but the code will not be accepted without unit tests. To make good progress you will
need those unit tests early on anyway, preferrably you start with your tests and then implement the code that makes the tests pass.
Also JGit is available under the EDL, a very liberal license, so we can only depend on other very liberal licences. GPL is not one of those. Anything Apache, MIT, BSD is
generally ok.
Get started by getting the source. See http://wiki.eclipse.org/EGit/Contributor_Guide . Fixing some bugs is a good way of getting warmed up with the process for writing,
test and submitting code.
When there is a JGit implementation of your feature, you can start adding a GUI in EGit. There are lots of examples and books on the topic. This forum is not the best
place to get help on Eclipse plugins in general, I think.
-- robin
|
|
|
| Re: bisect [message #1271570 is a reply to message #1270949] |
Sat, 15 March 2014 14:26 |
R Shapiro
Messages: 386
Registered: June 2011 |
Senior Member |
|
|
Quote:There are already other plugins that use the CLI, and may therefore have
better compatibility with Git.
What are the update sites for these other plugins? I don't see any in the Market Place and a web search didn't turn up anything either.
If there are better ones out there already I'll certainly use them. Writing my own has been an interesting exercise, and functionally it's seems pretty solid. For sure it's very handy to be able to do SVN bridging, bisecting, bundle manipulation etc, from within Eclipse, a big improvement over switching back and forth between Eclipse and a terminal window.
But when it comes to user-friendly GUIs and the like, I don't have those skills. With limited GUIs it becomes difficult to support sophisticated operations that have lots of parameter options.
As for dependencies, I think you're misunderstanding what I'm after. I don't expect EGit to depend on what I'm developing (which in turn depends on Git). The opposite in fact: my plugin already depends implicitly on EGit variables. I'd like to make the dependency on EGit more explicit so that I can use more of what EGit already provides, for instance the branch/tag/reference selection gui.
I gather it's possible to 'extend' an existing plugin, but I haven't investigated this at all. Is EGit extendable in this way?
|
|
|
| Re: bisect [message #1271851 is a reply to message #1271570] |
Sun, 16 March 2014 11:16 |
Robin Rosenberg
Messages: 332
Registered: July 2009 |
Senior Member |
|
|
R Shapiro skrev 2014-03-15 15.26:
> Quote:
>> There are already other plugins that use the CLI, and may therefore have better compatibility with Git.
>
>
> What are the update sites for these other plugins? I don't see any in the Market Place and a web search didn't turn up anything either.
Google it :)
I know we get bugs reports for something that begins with com.aptana, i.e part of an Aptana Studio. People also started working on some other, but apparently lost interest
when we wouldn't hang on. Forgot their names and they apparently aren't in visible range of page rank. One of them, I think, might have had some potential.
> If there are better ones out there already I'll certainly use them. Writing my own has been an interesting exercise, and functionally it's seems pretty solid. For sure
> it's very handy to be able to do SVN bridging, bisecting, bundle manipulation etc, from within Eclipse, a big improvement over switching back and forth between Eclipse and
> a terminal window.
I believe the Aptana Studios plugin is only "competitor". For the reasons I mentioned in the previous post, it will never replace EGit.
Writing a plugin is an interesting exercise. You are not likely to keep it alive by yourself for long, which is why the EGit is an Eclipse project since 2009.
> But when it comes to user-friendly GUIs and the like, I don't have those skills. With limited GUIs it becomes difficult to support sophisticated operations that have lots
> of parameter options.
Creating a good GUI is an *art*. Excercise helps and expect to fail a number of times (as we do). If you have any good tips, tell us! We want to have an UI that is easy to
learn and easy to use plus it should help when learing Git. The good part is that if you do the plumbing in JGit for e.g. bisect, then someone more GUI savy can do that
part for you. That is not meant to imply that implementing bisect in JGit is an easy task, but it doesn't require GUI design skills.
> As for dependencies, I think you're misunderstanding what I'm after. I don't expect EGit to depend on what I'm developing (which in turn depends on Git). The opposite
> in fact: my plugin already depends implicitly on EGit variables. I'd like to make the dependency on EGit more explicit so that I can use more of what EGit already
> provides, for instance the branch/tag/reference selection gui.
We don't write all code from scratch. We use things from external libraries, e.g. JSch. JSch is a dependency.
> I gather it's possible to 'extend' an existing plugin, but I haven't investigated this at all. Is EGit extendable in this way?
Yes, it is. We provide API's. JGit exports most of it as API's and EGit exports some of its functionality. You can look at the bundles' MANIFEST.MF file for
the section names Export-Package.
The most important bundles are org.eclipse.jgit, org.eclipse.egit.core and org.eclipse.egit.ui.
org.eclipse.jgit is a library that you call while org.eclipse.egit.core is both a library and a set of extension points that allow you to change how the eclipse plugin
behaves. We don't have many extension points right now. We add new ones when we need them.
In JGit you should try to stick to the package org.eclipse.jgit.api as much as possible. It the "porcelain" API, while the other stutf is low-level. We provide API
documentation in the form of JavaDoc and Unit tests, plus occasional pieces at the EGit/JGit wikis.
Anyone can contribute code to EGit, either as bug fixes, improvements, or new extension points for use in external plugins, provided they are good enough.
-- robin
|
|
|
| Re: bisect [message #1271933 is a reply to message #1271851] |
Sun, 16 March 2014 16:48 |
R Shapiro
Messages: 386
Registered: June 2011 |
Senior Member |
|
|
Quote:For the reasons I mentioned in the previous post, it will never replace EGit.
I wouldn't want replace EGit, it's probably my favorite Eclipse plugin, certainly the one I use most often. My plugin is not remotely intended to be a replacement, it's more like a short term place-holder. Its only purpose is to support Git operations I use regularly that are not yet supported by EGit. As EGit support grows, my plugin will shrink. Eventually I expect the only thing mine will do is SVN bridging.
Here are the features that are important to me and that EGit doesn't yet support as far as I know:
recursive merge strategy
reset <ref> --<path> where path is a directory
reset --keep
reset --merge
light-weight tags
prune
bisect
bundles
the logging pattern: log ref1 ^ref2
diff --stat
svn
Maybe some of these are supported already in EGit and I just haven't found them yet?
Most of these I use every day. I could of course do these things in a shell, but to my mind that defeats the 'integration' aspect of an integrated development environment.
If I could do them in EGit that would be ideal. In the meantime, even with my basic GUIs it's a major win to have access to these operations directly in Eclipse. For that reason I think other readers of this forum could also make use of this plugin -- again, only until EGit supports the relevant features.
Regarding JGit, I use it already in other projects, it's been quite handy. I looked at the sources to get a feel for how difficult it would be to add bisect and concluded that it would take far more time than I have available. Probably something like bundle support would be better way to get into JGit development. Bundles are very important for anyone working on hosts that are not on the open internet.
|
|
|
Goto Forum:
Current Time: Tue Apr 16 07:21:16 GMT 2024
Powered by FUDForum. Page generated in 0.87186 seconds |
] 
Search
Help
Register
Login
Home
