Re: How it was at GitTogether'08 ?

[Jakub Narebski <jnareb@gmail.com>]

On Sat, 8 Nov 2008, David Symonds wrote:
> On Fri, Nov 7, 2008 at 5:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> 
> Here's my thoughts on some of these talks.
> 
> > Mon, Oct 27, 2008
> > -----------------
> > * Dscho: Contributing with Git
> >  http://www.youtube.com/watch?v=j45cs5_nY2k
> 
> It was a good intro, but I was expecting a few more non-GitTogether
> people. We had quite a large room, but there was only about a dozen
> other people who came along. I don't know whether that was the fault
> of the timing, lack of advertising, or a lack of interest.

By the way, it would be nice to have transcript for this talk, just
like there is for Linus talk:
  http://git.or.cz/gitwiki/LinusTalk200705Transcript
(but this would take some doing).
 
It would be also nice to have slides for the talk available somewhere,
just like slides for "Git Chronicle".

> > * Junio: Git Chronicle
> >
> >  blog: Junio went though a sort of statistical history of the Git project
> >  that was fascinating (turns out there are still about 220 lines of code
> >  still around from Linus original first commit).
> 
> This was really interesting. It would be great to put this on a
> general web page instead of in a PDF.

Something like Sam Vilain slides from "perl.git" talk?, 
  http://utsl.gen.nz/talks/perl-history/slides/

It shouldn't be that hard, depending on the original program the slides
were made... well, it was made in Impress from OpenOffice.org 2.4; it
might have export to (X)HTML + images, and to SWF (Flash presentation).

> > * Petr: Renames Again and Again and Again
> >
> >  IRC: detection of wholesame renames of directories (WIP) and '--follow'
> >  limitation were mentioned, but outcome is unclear; pasky plans to hack
> >  together some patch implementing explicit renames hinting
> 
> One thing I didn't get around to bringing up: one of the benefits of
> diff-time rename detection that is often touted is that algorithms can
> improve over time. Do folk here know whether that has actually
> happened recently, in a general way? Do people actually expect major
> improvements in the future?

If I remember correctly there was at least one improvement in rename
detection, namely better talking into account filename similarity score,
so for example similar files moved (or copied) didn't get marked as
coming from one source (and rest deleted).

> > * Tom: GitHub
> >
> >  IRC: a tour, some history, and insight into how it works; some nice
> >  gimmicks, such as "gist" (a git backed pastebin), or like network graphs
> >  (look graphically at forks of a repository).
> >
> >  blog: Tom got to demonstrate GitHub and Gist to the group, most of whom
> >  are very command line oriented and had not used either before.
> 
> The demo of iGitHub (an iPhone app that can act as a clone/push
> target) looked really cool, if it can get further development. It
> could potentially be really handy for travellers who could push to
> their iPhone, and then push from there to an internet server.

iGitHub has nothing to do with GitHub; I think you put the comment in
a wrong place; the iGitHub (or iGit / iGitRouter) was a separate talk
in "Lighting Round Talks" next day.

> > * Scott: Linkable Library
> >
> >  blog: got to talk about the need for a linkable git library
> >
> >  http://thread.gmane.org/gmane.comp.version-control.git/99608
> 
> It's good to see this starting to get wider traction. I think we
> discussed that there could be benefits to git itself, beyond just
> helping other programs access git repositories faster than fork/exec.

What benefits would be those? Current design of "fire and forget",
which stopped libification efforts till now was used for a reason...

> > * Sam: perl.git
> >
> >  blog: Sam demonstrated the work he went through to import 20 years of Perl
> >  history into the git repository that the Perl team is just now finishing
> >  transitioning to from Perforce.
> >
> >  http://utsl.gen.nz/talks/perl-history/slides/
> 
> It was very cool to see old-school email addresses like <isis!aburt>
> in git, handled just fine.

This is not suprising, as Git treats committer and author email data
as opaque data, not analysing it at all (some commits from early
versions of git might not have this data at all, IIRC).
 
> > * Tim: Git as a Media Repository
> >  http://www.thousandparsec.net/~tim/media+git.pdf
> 
> This has kicked off some mailing list discussion; I think this can be
> a major weak point for git, since checking out only a subtree (and
> only the latest revision) is the common SVN way, which copes with
> media repositories and the like just fine.

Well, you can workaround this weakness by (ab)using submodules...
...and one should always remember that casual partial checkouts
interfere a bit with whole-tree commits.

-- 
Jakub Narebski
Poland