Categories
Eclipse Java

EGit pushes all local branches when no explicit RefSpec is found

Cloning a Git repository with EGit 1.0 and no further configuration causes some unexpected behavior. The moment you clone a repository, say from GitHub, everything is set up for you, and you are ready to push and pull. And since you fully adopted the Git workflow, you do create a new branch for every bug fix or new feature you are implementing. And you expect those branches to be local only. The problem with EGit is, they aren‘t. Instead, without further configuration, all branches are shared (pushed) by default.

As the Git push spec points out (refspec in options), this is correct:

The special refspec : (or +: to allow non-fast-forward updates) directs git to push “matching” branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side. This is the default operation mode if no explicit refspec is found (that is neither on the command line nor in any Push line of the corresponding remotes file—see below).

But on the command line, e.g. with msysGit or on OS X, this is different. No branch is pushed by default, you have to explicitly do this. This behavior seems more useful, since most branches are not of any interest to other developers.

To avoid this strange behavior in Eclipse, every(!) developer with push rights to this Git repository has to update his local RefSpec: Select Team – Remote – Configure Push to Upstream… You can see the setting causing the problem at the bottom right away (section RefSpec): All branches will be pushed using Push Spec “refs/head/*:refs/heads/*”

Expand the Advanced section and click on the Edit button. A new dialog opens. Check the source ref combo and select the master [branch] entry. This automatically updates the destination ref. Keep this entry and click the Add spec button, Finish and then Save in the other dialog. That‘s it. From now on, only the master branch is pushed to the remote repository. In case you want to push another branch, you do have to configure it as described above too. Remember to do this for every Git repository in every workspace.

That‘s it. Unfortunately, every developer has to do this. In my eyes, this is way to complicated. The settings described here should be the default. Developers want to develop, and not to configure the same things all the time again and again. And since push and pull are enabled directly after cloning, everything seems ready.

Because of that, I have started a post in the Eclipse Community Forums. In my eyes this qualifies as a change request. As a compromise it should be possible to implement some choice in the Eclipse preferences which updates the repository parameter push.default (seems to be ignored at the moment).

Categories
Eclipse

Push up your code – next generation version control with (E)Git @ Java Forum Stuttgart

The slides from my talk Push up your code – next generation version control with (E)Git today at the Java Forum Stuttgart are available for download. All the other slides are available here.

Categories
XML Encryption XML Security XML Security Tools XML Signature

XML Security tutorials now on GitHub

The German XML Security tutorials are now developed on GitHub. This does not affect the Eclipse XML Security Tools at all; the German tutorials will never be integrated there. The sources are only used to generate the tutorials available on my home page.

I'm working on some content updates. As soon as this will be finished I'll provide a new html version.

Categories
JCrypTool XML Security Tools

Integrating XML Security Tools into JCrypTool – chapter 2

More updates for the XML Security Tools in JCrypTool: download our latest pre release candidate 5 build and enjoy a working Digital Signature wizard! Most of the other stuff is working too, at least partly.

Feel free to report bugs or missing features, your feedback is always welcome.

Categories
JCrypTool XML Security Tools

Integrating XML Security Tools into JCrypTool – chapter 1

The first commands of the XML Security Tools are running in JCrypTool! Download our latest pre release candidate 5 build and have a first look. There is still a lot to do, only the XML Canonicalization is fully working so far. And most of the documentation is available. The integrated Apache XML Security library has been updated to version 1.4.5, the latest available. Even more modern than the official Eclipse XML Security Tools (since there is no IP-check at JCrypTool)…

Categories
Eclipse Java

My session at the Java Forum Stuttgart

My session for the upcoming Java Forum Stuttgart, Push up your code – next generation version control with (E)Git, was accepted! May session takes place at 12:15 p.m. (D4). As you can probably guess, it is about Git, especially about the Eclipse version EGit. The slides are in English, but I'll be speaking German.

See you here in Stuttgart on July 7th, 2011! And don't forget to visit us at the Trivadis booth in the exhibition area!

Categories
Eclipse

Eclipse WindowBuilder release available

There are tons of really good Eclipse plug-ins out there. But a really good GUI builder wasn't available so far. This has changed with the WindowBuilder proposal in December 2010, announcing the relocation of the famous (and formerly commercial) Eclipse GUI builder plug-in to Eclipse. WindowBuilder is now an official Eclipse plug-in, finally making available a really great GUI builder for Eclipse. And the first incubator release (version 0.9.0) is already available for download. Don't be afraid by the incubator icon, every Eclipse code donation has to start as an Eclipse incubator project. Time to download and install this plug-in right away!

Categories
Eclipse

Checking out a deleted project at a particular revision with Subversive

I have tried to check out a deleted project (a plug-in project in this case) from the JCrypTool Plug-ins repository today with Eclipse Subversive. I couldn’t figure out a good way to do this. The only solution I came up with was to find the revision in which this folder still existed and to use the Find/Check Out As… wizard to locate all projects in this particular revision in the repository and to select the single project I was interested in. Which in our case took a little while since all our projects do have their own branches, tags and trunk folders. And we do have a lot of projects… My only alternative idea was to export the content of our repository at this revision and to import the project temporary.

Both ways are far from being perfect. Does anybody know a better solution for this problem? It seems to be a quite common task.

Categories
Eclipse XML Security Tools

Developers wanted

As you might know, I‘m the component lead for the Eclipse XML Security Tools. Since my time is very limited, I haven‘t done much lately. Which is sad, since XML Security is an important topic in the ever growing web services world. And Eclipse is a great platform!
That‘s the reason why I‘m looking for new developers and testers or normal users providing feedback. There is no fast way becoming an Eclipse Committer, and it is not my intention to create one. But what‘s about getting started by filling out some bug reports, providing patches or other feedback?

Interested? Please do not hesitate contacting me or leaving a comment! Or fill out a bug report right away…

Categories
Eclipse JCrypTool

The org.eclipse.compare trouble

Recently we have upgraded JCrypTool from Eclipse 3.5 to Eclipse 3.6. And had to bring in a bunch of new plug-in dependencies since org.eclipse.equinox.p2.ui.sdk suddenly required org.eclipse.compare (and of course org.eclipse.compare required some more plug-ins).

Thanks to Kai‘s Blog there is a solution for this problem now (or better a workaround). My question is, why is this necessary? There is a recommendation to not use any IDE related plug-ins inside an Eclipse RCP. A perfectly good recommendation for most of the applications out there. But org.eclipse.compare requires org.eclipse.ui.ide, and there you go. The next thing is, the modified ui.sdk (as described by Kai) is working fine, no problems at all. Why does a RCP developer have to modify an original plug-in this way? Isn‘t RCP supposed to make your development easier? Isn‘t p2 the future (and already the present) of updating your RCP? Isn‘t an optional dependency on org.eclipse.compare the better solution? Or a fragment that brings in the functionality that requires org.eclipse.compare? In my eyes the latest org.eclipse.equinox.p2.ui.sdk plug-in is a step backwards. Not a huge one, but it is going the wrong direction…