Blog

  • 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).

  • JCrypTool on GitHub

    JCrypTool moved to GitHub! Migration was a little pain in the ass, mostly due to our somehow strange project structure in our Subversion repositories on SourceForge. The new repositories on GitHub are much cleaner and easier to use. Besides that, of course, GitHub (and Git) is much faster. Our projects at SourceForge will be read-only immediately, all content will be archived.

    Our new project home is now located at https://github.com/jcryptool. We still have two repositories: core and crypto (crypto was formerly known as plugins). Our wiki is part of the core project and is located at https://github.com/jcryptool/core/wiki. More content, besides Getting started as a JCrypTool developer, will be available soon.

    Besides that, we have created two new Google groups: JCrypTool Users and JCrypTool Developers. Feel free to join! And of course feel free to join the JCrypTool community by developing your own crypto plug-in!

  • New JCrypTool Developers and Users groups at Google

    The JCrypTool Developers and JCrypTool Users groups are now located at Google groups. The new developers group is available here: http://groups.google.com/group/jcryptool-developers. And the new users group is available at http://groups.google.com/group/jcryptool-users. Feel free to join the JCrypTool community!

  • JCrypTool full-screen support on Mac OS X 10.7

    Thanks to Alex Blewitt's blog post JCrypTool now offers full-screen support on Mac OS X 10.7. Not a perfect solution, since some Eclipse internals are used which create the corresponding Java compiler warnings. But better than no full-screen at all. The visualizations look just great in full-screen! Hopefully Eclipse will provide an official solution for full-screen support with Indigo SR1.

    This feature, among others, will be available in our next weekly build and of course the next official release sometime in August 2011.

  • 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.

  • 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.

  • Follow me on Twitter

    I’m now on Twitter, feel free to follow me

  • 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.

  • 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)…

  • 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!