GitTogether 2008, which took place October 27(Mon)-29(Wed), has ended more than week ago. Therefore I'd like to ask you impressions (while it is still fresh) from GitTogether, describe talks which are not described below, correct wrong information in below, etc. Please reply to this email while GitTogether is on front of your mind... Talks at GitTogether 2008 ========================= Mon, Oct 27, 2008 ----------------- * Dscho: Contributing with Git http://www.youtube.com/watch?v=j45cs5_nY2k * 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). http://userweb.kernel.org/~junio/200810-Chron.pdf * Jeff: Helping new contributors join * 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 * Sam: GitTorrent IRC: briefly the history if GitTorrent: way underannounced, not completely finished, GTP/0.1 was "published" long ago. There was a GSoC project this year, mentored by mugwump. Unfortunately, the student turned out to be a procrastinator or something, and this project was mainly pushed forward by the mentor. Now after the summer, mugwump took a step back and analyzed the protocol with all the experience won from implementing a large part of it. Turns out that a lot of the stuff was not really necessary, but copied because the BitTorrent protocol had it all. So, plan is to really strip down GTP. And not have a separate protocol for GitTorrent, but rather have it as part of git-daemon. [...] Turns out that warthog9 had a few really important things to say that should end up (at least in the 2nd version) in having a more robust discovery/exchange. ...
Can someone elaborate on this? AFAIK, notes have popped up on this list often enough that I'm convinced it would be a _really_ useful feature. The only drawback I was aware of, was the lack of an efficient implementation, but then Jeff comes out of the blue and posts some interesting numbers  a week or so ago. Does this mean there are no remaining obstacles? : http://article.gmane.org/gmane.comp.version-control.git/99415 Have fun! ...Johan -- Johan Herland, <firstname.lastname@example.org> www.herland.net --
The discussion was along the lines of "here are some more cool things we could do, if we had notes." I don't remember the specifics of the cool things, but they were related to annotating patches with review information. Shawn can probably elaborate more. That led to a "notes as a tree are nice, but too slow because looking up a tree entry is linear" (and obviously you do a ton of lookups in the notes tree during "git log"). Dscho had posted an implementation with a persistent notes cache long ago. Since I failed to actually look at that, I started on a slightly different approach, which is simply doing an in-memory hash table to speedup the notes tree. And those are the numbers and patch I posted. My eventual plan was to re-work Dscho's patches with this performance approach. But it is not at the top of my queue, so if somebody else wanted to pick it up, I would be very happy. Everything I have done so far is in the post you referenced. The only other thing I remember discussing was notes namespaces. The two obvious approaches are: 1. a separate ref for each notes namespace, with each note ending up a blob in a tree. So you might have refs/notes/acked-by:$SHA1 as a blob. 2. one notes ref, with the notes tree pointing a sub-tree that has named entries, one for each note type. So you might have refs/notes:$SHA1/acked-by as a blob. The advantage of '1' is that it keeps your different note types separate, which means it is easy to distribute one type but not the other. The advantage of '2' is that I do one lookup per-commit, and then I can see all of the notes, which keeps performance nice when you want to annotate with several note types. After some discussion, I think Dscho and I came to the conclusion that supporting both might be desirable. And it should be pretty straightforward. You can just have multiple note refs (but default to a "main" one), and within each one, either point to a tree or blob (and we will see which and use it ...
On Fri, Nov 7, 2008 at 5:54 PM, Jakub Narebski <email@example.com> wrote: 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 This was really interesting. It would be great to put this on a 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 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 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 It was very cool to see old-school email addresses like <isis!aburt> 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 Yes, how are the t-shirts going? I seem to remember JH had volunteered to do the logistics there. Dave. --
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, 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 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 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 What benefits would be those? Current design of "fire and forget", This is not suprising, as Git treats committer and author email data as opaque data, not analysing it at all (some commits from early 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 --
Interesting. How would you use submodules to work around the fact that bina= ry=20 file changes diff very bad and produce huge histories with basically no val= ue=20 for the user of the working copy? Can you do this from a GUI, easily? We're= =20 talking about media repositories here, so our users are artists. Cheers, Kai =2D-=20 Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ =2D- Will code for cotton.
What I meant here (but perhaps was not clear) was (ab)using submodules to allow to have full working repository without large [media] files both in object database (repository) and without them checked out. The workaround is to put all large files for example in 'media/' folder, and make this folder be submodule. Each clone of repository can have this 'media' submodule either present (both in object database, although usually separate from main project object database), or not present (not cloned and not checked out). As to submodules UI and GUI support for submodules... currently it is unfortunately lacking. Note that I explicitly mentioned that (ab)using submodules to better deal with large files is _workaround_, and not _solution_. Lazy clone in version proposed by Tim is IMHO correct solution. P.S. Could anybody document at last `delta' gitattribute? P.P.S. You can have separate diff driver for binary files, but I don't know anyone who uses for example some such for images... -- Jakub Narebski Poland --
Tim was talking about that media/ folder and managing that in git. If you w= ant=20 to work on the media, you might end up getting hundreds of gigabytes of dat= a=20 to get that folder, even if you only need to change one single file. That's the issue we're running into, and I don't thing submodules solve thi= s=20 at all. Cheers, Kai =2D-=20 Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ =2D- Will code for cotton.
Ah, well... Submodules cannot be workaround for _this_ issue. You can have only all or nothing: either all files in media/ or none of them, both in working directory like in repository object database... well unless you subdivide further. I guess that mentioned work on the media is in remote setting (you cannot have main repository on network drive) so Dana How's proposed solution would not work for you, is it? -- Jakub Narebski Poland --
If my google-fu worked, the proposed solution you're talking about involves= =20 simply hiding large blobs from pack files, right? In that case it won't wor= k,=20 as the users of the repository indeed are remote. Cheers, Kai =2D-=20 Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ =2D- Will code for cotton.
Hi, You'd have to have a single repository for each and every media file, and you'd need to use shallow clones and shallow fetches. However, a push-conflict will probably be beyond any non-programmer skillz. I'd rather propose to have a different interface, like through a web server, where the user can say "I have some cool new graphics, in this .zip file" together with a commit message. Kind of a git-gui via browser. Ciao, Dscho --
On Monday 10 November 2008 10:58:05 Johannes Schindelin wrote: Ok, I agree. But you could work around that by teaching the artists to=20 fetch/rebase/push instead of just pushing, or hiding this in the GUI. If=20 Incidentally I'm currently working on something like this, just aimed at=20 the "artist side", instead of the VCS side. This certainly is a useable=20 solution for artists. But at some point a developer will want to check out= =20 the repository to cut a release tarball, and we're back to wanting shallow= =20 and narrow clones. :) Cheers, Kai =2D-=20 Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ =2D- Will code for cotton.
Hi, A fetch in that case would make the artist download things she does not Shallow clones are not an issue. They _should_ work. And for releasing you do not want narrow clones. Ciao, Dscho --
Hi, Voila: http://repo.or.cz/w/git/dscho.git?a=blob_plain;f=all-your-rebase.pdf;hb=f23c1c9868256c... Ciao, Dscho --
Still missing (neither video, nor slides, nor description, nor email) + What was the difference between "Tim: Large media in Git (Repeat)" from Wed, and earlier "Tim: Git as a Media Repository" from Tue? -- Jakub Narebski Poland --
Here are the slides from David's and my talk: http://docs.google.com/Presentation?id=dhhs72s2_1wtzbnsnj&invite=v4t8kr -Steve --
Requiring a google (or facebook for that matter) account is read public documents is not nice. -- robin --
No, its not. The owner of the document can publish the document, making it world-readable, *without* needing a login. I think they just forgot to do that on this particular presentation. Steven, can you publish that doc, so it doesn't require login to read? -- Shawn. --
My bad. Here's the published, no-login-required version: http://docs.google.com/Presentation?id=dhhs72s2_1wtzbnsnj -Steve --
Hi, I also included whatever I could grab (did not take care of mugwumps html pages yet) into my presentations branch. Ciao, Dscho --
JGit slides: http://www.spearce.org/2008/11/JGit.pdf Pack v4 slides: http://www.spearce.org/2008/11/Pack_v4.pdf I also had these as a Google Doc, but its internal on the google.com domain so I can't easily publish it. Plus PDF is probably more portable to older browsers than the Google Docs site is. :-) -- Shawn. --
The first day I got people feed back on my proposal (whiteboard discussion) and then presented the proposal on Wednesday. You can find the slides of the presentation at http://www.thousandparsec.net/~tim/media+git.pdf Sorry about the duplicate messages, I hit send too soon. Tim 'mithro' Ansell --
Do such git shirts exist already and could be ordered somewhere? I might be interested in buying one. Cheers, jlh --
I really enjoyed this talk, which was in a weird sense very encouraging. By the way, one thing David talked about that is not in the PDF slides but I found quite good to stress was the importance of good commit messages. "Write in present tense, it will read much nicer and you'll appreciate it after reading hundreds of them". I'd actually say "imperative mood" instead of "present tense" (but they look almost always the same in English), but in any case, it really gets on my nerve to read commit message that talks things in past tense and I often end up rewriting other people's commit log messages. --
|Paul Turner||[tg_shares_up rewrite v4 11/11] sched: update tg->shares after cpu.shares write|
|Mr. James W. Laferriere||Re: Linux 2.6.25-rc1 , syntax error near unexpected token `;'|
|Chuck Ebbert||Re: PCI: Unable to reserve mem region problem|
|Mingming Cao||Re: [RFC 1/4] Large Blocksize support for Ext2/3/4|
|Linus Torvalds||Linux 2.6.34-rc4|
|Ralf Wildenhues||[PATCH] Fix typos in the documentation|
|Adeodato||Bazaar's patience diff as GIT_EXTERNAL_DIFF|
|Johannes Schindelin||Re: [PATCH 2/4] Add functions get_relative_cwd() and is_inside_dir()|
|Len Brown||Re: fatal: unable to create '.git/index': File exists|
|Denis Bueno||Git clone error|
|Linux Kernel Mailing List||ASoC: fix registration of the SoC card in the Freescale MPC8610 drivers|
|Linux Kernel Mailing List||drivers/acpi: use kasprintf|
|Linux Kernel Mailing List||nfsd41: sanity check client drc maxreqs|
|Linux Kernel Mailing List||bnx2x: Moving includes|
|Linux Kernel Mailing List||V4L/DVB: gspca - sonixj: Adjust minor values of sensor ov7630. - set the color ga...|
|Sevan / Venture37||Re: This is what Linus Torvalds calls openBSD crowd|
|Netmaffia.hu||Tini Lányok AKCIÓBAN OTTHON|
|Sam Fourman Jr.||Re: Help with Altell PC6700|
|Siju George||This is what Linus Torvalds calls openBSD crowd|
|Darrin Chandler||Re: OT: Python (was Re: vi in /bin)|
|Kurt Van Dijck||Re: [PATCH net-next-2.6 1/2] can: add driver for Softing card|
|Eric Dumazet||Re: [PATCH net-next-2.6] net: Introduce skb_orphan_try()|
|Jamie Lokier||Re: POHMELFS high performance network filesystem. Transactions, failover, performa...|
|David Miller||Re: [PATCH v2] net: typos in comments in include/linux/igmp.h|
|Ursula Braun||[patch 0/1] remove header_ops bug in qeth driver|