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

Do such git shirts exist already and could be ordered somewhere?

I might be interested in buying one.
Cheers,

jlh

--

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

--

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

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.

--

Thanks. Added to http://git.or.cz/gitwiki/GitTogether
--

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

--

Would it be possible to publish PDF version sowehere, for example

as attachement to http://git.or.cz/gitwiki/GitTogether? My old

web browser doesn't support Google Docs...
--

Jakub Narebski

Poland

--

http://docs.google.com/MiscCommands?command=saveasdoc&docID=dhhs72s2_1wt...
--

Jonas Fonseca

--

Hi,
I also included whatever I could grab (did not take care of mugwumps html

pages yet) into my presentations branch.
Ciao,

Dscho
--

Thanks. Added to http://git.or.cz/gitwiki/GitTogether

(even if I cannot view them in my old web browser).
--

Jakub Narebski

Poland

--

On Fri, Nov 7, 2008 at 5:54 PM, Jakub Narebski <jnareb@gmail.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

--

Hi,
Voila:
http://repo.or.cz/w/git/dscho.git?a=blob_plain;f=all-your-rebase.pdf;hb=...
Ciao,

Dscho
--

Thanks a lot. Added to http://git.or.cz/gitwiki/GitTogether
P.S. I guess GitTogether wiki page should be perhaps rewritten...

--

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.

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

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.

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 [1]

a week or so ago. Does this mean there are no remaining obstacles?
[1]: http://article.gmane.org/gmane.comp.version-control.git/99415
Have fun!
...Johan
--

Johan Herland, <johan@herland.net>

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 appropriately)....
[ message continues ]