00:21 (quit) nicktick: Remote host closed the connection
00:23 (join) jonrafkind
01:31 (join) jeapostrophe
01:36 (quit) jonrafkind: Ping timeout: 265 seconds
01:47 (quit) jeapostrophe: Quit: jeapostrophe
02:08 (join) nicktick
02:36 (quit) nicktick: Ping timeout: 245 seconds
02:42 (join) nicktick
04:10 (quit) nicktick: Ping timeout: 245 seconds
04:11 (quit) eli: Ping timeout: 264 seconds
04:16 (join) nicktick
04:31 (join) eli
05:32 (quit) nicktick: Remote host closed the connection
05:46 (quit) adadglgmut: Max SendQ exceeded
05:46 (join) adadglgmut
06:51 (join) nicktick
07:50 bremner: eli: since it's morning, you are probably asleep :). But I just posted some thoughts about workflow to #git for feedback. http://paste.debian.net/79170/
07:56 (quit) jao: Ping timeout: 265 seconds
07:57 (quit) RyanRN: Ping timeout: 245 seconds
08:14 bremner: eli: http://nvie.com/git-model   seems to capture what I was trying for, but in a nicer way.
08:34 bremner: I mean, at least the big picture of master, develop, and release branches.
08:38 (quit) nicktick: Remote host closed the connection
08:47 (quit) huma: Ping timeout: 260 seconds
08:47 (join) huma_
08:47 (nick) huma_ -> huma
08:55 (join) nicktick
09:28 (join) jeapostrophe
10:53 eli: bremner: so you have three points there, with the new ones being 2-4.
10:54 bremner: right
10:54 eli: I wonder if 2 is really needed -- having the release branch stay alive forever means that if you track its history you get something very different than what happened on master, which is where it all happened.
10:55 eli: And 3 is not really practical -- I have to assume that some people will always use git in a very simple way -- not using any branches.
10:55 eli: (Otherwise they'll surely commit to the wrong branch.)
10:55 eli: (That's not due to svn, btw -- it's been that way in svn too...)
10:56 (quit) nicktick: Remote host closed the connection
10:56 eli: But 4 sounds interesting -- if I do only that (merge the release to the trunk), it seems like things should improve, no?
10:56 bremner: well, in the language of  http://nvie.com/git-model step 2 is where bug fixes are merged back into develop.
10:56 bremner: yes.
10:57 bremner: wait. step 2 is where releases catches up with master.
10:58 eli: I don't remember the details, by my impression on that was that it was heavy on the "specific target branches for different kinds of commits", with lots of merging going around.
10:58 eli: Whereas I do the cherry picking myself, instead of merging.
10:58 bremner: the problem is that merging after cherry-picking is not going to work very smoothly, afaik
10:59 eli: But other than that (and the fact that the release/master branches last forever), I think we're doing something very similar.
10:59 eli: Yes, I know.
10:59 eli: I'm thinking of finding some git magic that will make it a no-op commit on the master.
11:00 eli: IOW, the only purpose of the commit will be to tie the branch back to the master -- not to change anything.
11:02 bremner: not sure, but a merge commit basically does that. The problem is currently there is no easy access to what is common history. It just looks like two parallel trains of development, even though most of the commits are conceptually the same.
11:03 bremner: it seems like part of the answer should be that the releases are merged into some "golden" branch other than master, if we assume all commits start in master.
11:04 eli: Here it is: git merge -s ours release
11:04 eli: That's what I was trying to find.
11:09 eli: bremner: In any case, I've added an item on my checklist to do this merge now, and I'll see how it looks like when we get there.  (Which should be soon...)
11:21 bremner: eli: as long as you are sure that all of the commits on the release branch are cherry-picked, and not directly added, that should be ok.  Or I guess thinks like updating the README file that you don't mind losing.
11:27 eli: bremner: That's almost always the case -- there are *no* changes that happen on the release branch that are not cherry picked.
11:27 (join) shofetim
11:27 eli: There are only two exceptions for that:
11:28 eli: In some very rare cases, there's a change on master that doesn't apply cleanly on the release branch, and in that case we'd fix it manually (and this has happened twice so far, IIRC).
11:28 eli: And the second is the version number which is bumped on the release branch independently from the master -- but that should obviously go away with such a merge.
11:29 eli: There's nothing other than that -- including the README file.
11:29 eli: (Actually, the README file is static, and uses an attribute to get stuff into it, and a small patchup that is done by the build process.)
11:46 (join) nicktick
12:01 (join) jonrafkind
12:02 (join) carleastlund
12:09 (join) Matrox
13:54 (quit) nicktick: Remote host closed the connection
14:13 (quit) jeapostrophe: Quit: jeapostrophe
14:39 (quit) adadglgmut: Max SendQ exceeded
14:40 (join) adadglgmut
15:07 (part) mattmight
15:07 (quit) shofetim: Ping timeout: 260 seconds
15:08 (join) mattmight
15:37 (join) jeapostrophe
16:12 (join) noelw
16:12 noelw: Aloha
16:12 noelw: There used to be a way to make a struct masquerade as a function
16:12 noelw: Does this still exist?
16:12 noelw: I can't find it in the docs...
16:12 noelw: (I'm fairly it is still there somewhere...)
16:13 noelw: prop:procedure
16:14 noelw: Documented up procedures, not structs
16:15 (join) shofetim
16:17 jonrafkind: noelw, ill add a note in the docs for structs
16:17 noelw: Thanks
16:19 noelw: copy-directory/file is wack
16:19 jonrafkind: whats wrong withi t
16:20 noelw: Specifically, (copy-directory/files "src" "dest") doesn't work if dest is a directory that already exists
16:20 noelw: as c-d/f always tries to create the directory first
16:20 noelw: This is odd, IME. It certainly isn't how the shell works
16:22 jonrafkind: yea it shoudl have a keyword parameter that makes it not fail if the directory exists
16:22 noelw: D'ya think? I think that should be the default behaviour if I'm copying one directory to another
16:23 noelw: I'm not sure what the intention of these functions is, but I'm assuming it is convenience
16:23 jonrafkind: the `struct' docs already have a note about applicable structs
16:23 jonrafkind: can the docs be clearer?
16:24 noelw: Where is the note?
16:24 jonrafkind: next to the #:prefab text
16:25 noelw: Ah...
16:26 noelw: If it was next to the text on properties that would be better
16:26 jonrafkind: yea, im not sure how to fix such layout issues
16:26 noelw: But, it is pretty close...
16:26 noelw: Well it is probably the best that can be done with reasonable effort, then.
16:29 noelw: I'm off. I can bitch about c-d/f over email if you like. I can even implement improvements!
16:31 (quit) noelw: 
16:45 (join) h_z12x
16:48 (join) shofetim`
16:50 (quit) shofetim: Ping timeout: 260 seconds
17:04 (join) lisppaste
17:22 (quit) huma: 
17:54 (join) h_z12x1
17:55 (quit) h_z12x1: Client Quit
17:56 (quit) h_z12x: Ping timeout: 276 seconds
18:06 (quit) shofetim`: *.net *.split
18:06 (quit) carleastlund: *.net *.split
18:08 (join) shofetim`
18:08 (join) carleastlund
18:19 (join) adamvh
19:00 (part) shofetim`: "ERC Version 5.3 (IRC client for Emacs)"
19:00 (quit) jay-mccarthy: Quit: jay-mccarthy
19:04 (quit) jeapostrophe: Ping timeout: 260 seconds
19:06 (join) erl_
19:07 (quit) erl_: Client Quit
19:17 (join) jeapostrophe
19:44 (quit) jeapostrophe: Quit: jeapostrophe
20:24 (join) RyanRN
20:31 (join) nicktick
20:42 (quit) jonrafkind: Ping timeout: 240 seconds
20:45 (join) shofetim
20:49 (join) jeapostrophe
20:52 (quit) carleastlund: Quit: carleastlund
20:54 (quit) jeapostrophe: Quit: jeapostrophe
21:04 (quit) RyanRN: Read error: Connection reset by peer
21:05 (join) RyanRN
21:15 (join) jeapostrophe
21:15 (quit) jeapostrophe: Client Quit
21:19 (join) ne
21:19 (quit) nicktick: 
21:28 (quit) Matrox: Read error: Connection reset by peer
21:43 askhader: what is meant by xexpr in http://docs.racket-lang.org/web-server/http.html?q=redirect-to#(def._((lib._web-server/http/cookie..rkt)._xexpr-response/cookies))  ?
21:54 eli: It's an s-expression-based representation for an xml element.
22:04 (quit) cky: Quit: rebooting
22:09 (join) jeapostrophe
22:12 (join) cky
22:16 (quit) jeapostrophe: Quit: jeapostrophe
22:39 (join) jonrafkind
22:47 (quit) RyanRN: Quit: Leaving.
23:19 askhader: eli: Hm, necessary for producing requests for headers?
23:29 (join) jeapostrophe
23:53 (quit) jeapostrophe: Quit: jeapostrophe