(Pretend that the recount is not subjective. At all.)
|Line 124:||Line 124:|
was that we should do this more often: Git together.
was that we should do this more often: Git together.
Latest revision as of 10:19, 14 January 2010
 "Alles Wird Git" Berlin GitTogether '09
- What: An informal gathering of Gits.
- Date: Saturday, October 3, 2009.
- Time: 10am until the end
- Where: http://www.zib.de/besucher/index.en.html
- Why: Gitzilla will be visiting and volunteered a $100 subsidy.
- Who: Any Gits that can attend. IRC handle starting with "git" not required.
- Steffen Prohaska
- Johannes Schindelin
- Sebastian Schuberth
- Sverre Rabbelier
- Jens Lehmann
- Heiko Voigt
- Christian Halstrick
- Michael Haggerty
- Thorsten ("I'm your user base") ?
- "Mac's your mistress, Windows' your wife" (Michael)
- "I'm your user base" (Thorsten)
- "We have 3 maintainers working on one master branch, and it is... working" (Steffen)
- [inappropriate joke censored]
- "Yes, it is possible. But it will be hard." (Sverre)
- "I am the ambassador of the ugly and the stupid" (Michael)
- "Michael talked about what Subversion can do that Git cannot" -- "And I wasn't even hurt!"
 Wrap up ("Alles wurde Git")
We were kindly offered hosting by the Zuse-Institut Berlin (thanks Steffen) and there was always a ready supply of coffee and snacks, as well as a pretty fast internet connection.
After a round of introductions (apart from Dscho, there were Michael Haggerty, Jens Lehmann, Heiko Voigt, Thorsten (I did not catch the surname), Sebastian Schuberth, Steffen Prohaska, Christian Halstrick and Sverre Rabbelier; Gitzilla and his friend Kristen joined us in the late afternoon), Dscho started out with a few (hopefully interesting) tidbits and trivia about msysGit. He also discussed the relationship between Cygwin, MSys, MinGW32 and msysGit, as well as why git-svn is so slow on Windows (and what one can do about it).
Then Michael talked a little bit about the versioning and the branching as well as common merging techniques in CVS, and how Subversion handles similar scenarios. It was interesting to hear that Subversion allows you to cherry-pick commits, and even parts of a commit, from other branches, and keep track of it (i.e. remember at a later merge that this was already merged, and take that into account). This is definitely something Git cannot do, and I can see that people could miss this feature after a SVN->Git switch. It was also suprising to learn that Subversion allows you to edit commit messages and even authorship after the fact, but not patches.
Sverre went on to describe his work on hg-git and his plans to integrate it as a foreign vcs, which was when we had quite a few words on the current state of affairs of the foreign vcs support. You all know the sad story of the design flaws. We also discussed the possibility of git-remote-svn, which was seen as the natural way to integrate Subversion repositories as proper Git submodules... _iff_ we will be able to specify the clone URL together with the type as one line (i.e. optimizing for the common case instead of the obscure one). One important outcome of that discussion was that we _cannot_ imitate git-svn there, as the commit messages and authorships can be edited (see above), so we would need to record the commits with a standard author and only the revision number as commit message, and put the mutable information into notes. Git-svn can get away with the way it does things because it is meant to be single-user only, but with remote-svn submodules, you have to make sure that _every_ user will get the same SHA-1s regardless of when they happened to clone the Subversion repository.
Then Thorsten, who described himself as "probably the only person in the room without commits in git.git, so I guess I'm your user base" let us have some glimpses of real-world problems with Git. One thing that was pretty obvious after thinking about it is the naming of branches. Git is way too liberal, e.g. it allows "git checkout -b origin/master", when clearly "-t" was meant (and a look around told me that _everybody_ had this problem at some stage). Unfortunately, it did not occur to us to discuss what can be done about these issues, let alone to make a list of them.
Jens offered some inside-stories of a company switching from RCS(!) to Git. He also described himself and Heiko as heavy users of submodules, and took some time to explain in how many ways submodules are the neglected ugly duckling of Git. He also showed us some of his work-in-progress to do something about it. Another part of the presentation was an in-depth account how important msysGit was to the adoption of Git in the company.
Christian, who is working for SAP, and recently got involved in the eGit/JGit story, related a few interesting facts about the company he works for. Already in 2001, they had a strong need for distributed version control, and came up with their own tool. When they realized just how far Git advanced, a rather surprising change in policy allowed him not only to look into eGit/JGit, but also to work on it. Which he did later that day, too, finding a bug in my diff implementation ;-)
Steffen and Sebastian then told us about another example of Git in a corporate setting. What some of the Open Source guys did not appreciate fully before that presentation was that some things that cannot happen in Open Source are unavoidable in a company. For example, you will always find people who work actively against having their patches reviewed. Another example is that accountability, and therefore code ownership, can be really necessary. Steffen also described some of the issues with working on a large number of topic branches that need to be integrated/cleaned up/rebased: Git lacks good tools for working collaboratively with topic branches that need to be rebased frequently. He also showed a rather complicated script that is necessary to coordinate work between 3 different maintainers (at 3 different locations).
We also got some hacking done, e.g. Heiko, Sebastian and Dscho on Git-Cheetah, and of course the utterly useful "mispel" patch (that has not made it into git.git yet, much to our chagrin). But most of the time we just had a good time and talked about what we love.
Oh, and Gitzilla entertained the whole party by recounting a few of the most hilarious emails authored by Dscho, who should not write mails after he had a beer.
The unanimous consensus at the end of the day, after we were for dinner, was that we should do this more often: Git together.