--- Log opened Fri Feb 10 00:00:12 2006 00:51 * jdl returns to idler central. 01:17 -!- Oejet [i=proxyuse@cpe.atm2-0-1071147.0x3ef2a7ea.boanxx10.customer.tele.dk] has signed off ("Download Gaim: http://gaim.sourceforge.net/") 03:57 < dmlb2000> hmmm, I'm a newbie when it comes to git, I removed some files from my git repo and want to revert them back to what is in the repo... but git-revert isn't doing what I expect... any suggestions? 03:58 * dmlb2000 is used to scm's like perforce or subversion 04:17 < pasky> cg-restore 04:21 < dmlb2000> hmmm so the git commands are too complicated??? 04:21 * dmlb2000 goes to install cogito... 04:43 -!- njs` [n=njs@66.92.218.83] has joined #git 05:43 -!- Newsome [n=sorenson@216-190-206-130.customer.csolutions.net] has joined #git 06:01 < jdl> You could "git checkout -f "? 06:02 -!- gittus [n=torvalds@ip187.82.dhcp-acs2.pdx.iinet.com] has joined #git 06:03 < jdl> Er, no -f in there. 06:03 < jdl> Just "git checkout " should do it. 06:04 < jdl> Hi gittus! 06:05 < gittus> jdl: don't mind me, I'm not an irc person, I just decided to look what it's like 06:05 < jdl> Heh. I will not betray you. :-) 06:06 < gittus> I was actually trying to google for irc logs to get a feel for what problems people have, but couldn't find any. So I'm just lurking to get a log that way 06:07 < jdl> I have about two days here. Here is the one from just a second ago: 06:07 < jdl> hmmm, I'm a newbie when it comes to git, I removed some files from 06:07 < jdl> my git repo and want to revert them back to what is in the 06:07 < jdl> repo... but git-revert isn't doing what I expect... any suggestions? 06:07 < jdl> Did that come through OK? 06:07 < gittus> I see that you already answered that one. 06:08 * jdl nods. 06:08 < gittus> dmlb20000: "git revert" is for actually reverting (re-doing in reverse) a commit you've done 06:08 < jdl> I asked about --diff-filter=*, but no answer here; found on list. 06:08 < jdl> nod 06:08 < jdl> There is a lot of "expectation" based on commands names. 06:09 < gittus> It probably doesn't help that some of the git commands are based on BK naming, not CVS naming 06:11 < jdl> True. But for Linux, np. 06:11 < jdl> Someone checked in here asking for debug help. 06:11 < jdl> Problem occured after "cp -r" on a .git repo. 06:11 < jdl> Problem was bad lack of symlink for HEAD when done. 06:12 * gittus shakes head 06:12 < jdl> Yeah. 06:13 < gittus> Yeah, easy enough to get that wrong. The git internal pseudo-symlinks actually protect against that particular problem, but still, people shouldn't go around copying the archives around.. 06:13 < jdl> Well, the docs say you can do it! 06:14 < gittus> You _can_ do it, you just have to be careful (use "-a" instead of "-r", or at least "-rp"). Also, you have to refresh the index afterwards (git update-index --refresh) 06:14 < jdl> nod 06:15 < jdl> BTW, I have a git intro paper coming out in Linux Magazine next month! 06:16 < gittus> goodie. one of the things that made me want to look at irc logs to see what people thought was that I happened upon some old SCM comparisons that talked about how hard git was to use, and I wanted to see what people felt _now_. More docs, better 06:17 < gittus> Anyway, I'm actually going to turn in with a good book, and leave the client going, and see what pops up. 06:17 < jdl> I think we are beginning to see those issues get ironed out on the list now. Discussions like the long "git diff-index --cached HEAD frotz n stuff" commands, for example. 06:17 < jdl> Those sorts of things tend to swim in newbie heads a bit too much. 06:18 < jdl> I think a clear, concise description of the Index is critical. 06:19 < jdl> What do you think is making "git hard to use" still? 06:19 < gittus> Well, I was actually hoping that people wouldn't use the internal "diff-tree" "diff-index" "diff-files" commands at all, and that we'd just have "git diff" (and it looks like we'll have a more useful "git status" too). No point in confusing people with the three different programs to generate the data. 06:20 < gittus> And no, _I_ don't think git is hard to use. A lot of operations are just _sooo_ much easier than they ever were in CVS. But the thing is, people think what they know is easy, so it's always interesting to see what new users first questions/stumbling blocks are. 06:20 < jdl> There is long standing tradition that " diff" yields the concept "what I have different than the repo". 06:21 < jdl> Right. 06:21 < jdl> I really meant to ask, "what do you _hear_ people say is hard?".. 06:21 < gittus> Well, "git diff" does kind of default to that. You almost have to know what you're doing for "git diff" to show anything else. 06:21 < jdl> Heh. Yeah. 06:22 < gittus> I don't actually hear people complaining. I only follow the git mailing list though, and that seems to be mostly "in the know" people. 06:22 < jdl> I have a crowd at work who need to be educated on git. 06:22 < jdl> I have done two brownbag discussions on it so far. 06:22 < jdl> I'll likely do more, so I will hear the feedback too.... 06:23 < njs`> gittus: heya 06:23 < gittus> One of my worries is actually that people are scared away by the old rumors, and they don't even use git at all, but cogito, and then I wouldn't even hear what problems they have (even if their problems are actually git problems, not cogito problems, but they'd be discussed at cogito mailing lists etc that I don't follow) 06:23 < jdl> That would be bad, yeah. 06:24 < jdl> I've been advocating straight git, actually. 06:24 < jdl> I kno. 06:24 < jdl> w. 06:24 < gittus> njs: hullo. I actually know you, because unlike git irc logs, I obviously long since found the #monotone logs 06:24 < njs`> right, I remember :-) 06:24 < gittus> (njs: apart from the few emails we exchanged, of course) 06:25 < jdl> BTW, I really like git. Thank you! 06:25 * gittus preens 06:25 < gittus> jdl: you're welcome. I like it myself. 06:26 < njs`> say, a random question I was curious about the other day -- if things suddenly magically changed now, and you could use either git as it is now, or bk again, which would you consider the preferred tool? 06:27 < njs`> (ignoring the various politics, lost community goodwill, etc. that would make any such possibility unlikely) 06:27 < gittus> njs: by now, I've made git do some things that I would have a hard time weaning myself off. 06:27 * jdl ponders dodecapus merges... 06:28 < gittus> For example, tracking particular subdirectories: this like "git whatchanged -p drivers/scsi/ include/scsi/" is literally something I do all the time. 06:28 < gittus> jdl: you'll go mad if you look at the octopus merges too much. 06:29 < jdl> Heh. I spent a large part of today doing "git whatchanged -p arch/powerpc" today! 06:29 < njs`> gittus: that's basically, display each patch that has been applied that touched anything in either of those places, walked down through history? 06:29 < njs`> (or up, or whatever one's preferred orientation is) 06:30 < gittus> njs: right. It's _very_ convenient. I almost never look at an individual file, but a particular sub-tree.. 06:30 < jdl> I wanted the combo of that and pick-axe the other day too. 06:30 < njs`> gittus: yeah, monotone calls it 'log --diffs', and I use it all the time too :-) 06:30 < jdl> Had to resort to "ah, this SHA1 from whatchanged, so diff that commit..." 06:31 < njs`> well, probably more on files, since I mostly am working on monotone itself, and monotone is like 30 source files or something. but same principle :-) 06:31 < gittus> Now, pick-axe is a bit strange. But you definitely shouldn't need to worry about sha1 06:32 < jdl> Well, what I wanted was more like: 06:32 < jdl> Take "git whatchanged -p arch/powerpc", but when you find a patch that touched one of those, give me the whole commit. 06:33 < gittus> jdl: what you want is actually something git does pretty well too. Try "gitk arch/powerpc" 06:34 < jdl> Oh, yeah, that worked fine too, btw! 06:34 < gittus> (Or, if you want to be really perverse, just do "git-rev-list HEAD -- arch/powerpc | git-diff-tree --stdin -p --pretty | less -S") 06:35 < gittus> Basically, "git whatchanged" does "git-rev-list HEAD | git-diff-tree --stdin -p --pretty -- arch/powerpc | less -S" 06:35 < jdl> Sadly, that make perfect sense as well. :-) 06:35 < jdl> Didn't think of it, but seeing it there makes sense. 06:36 < gittus> Notice how git-whatchanged will filter on the _diffs_, while gitk (and the first pipeline) will filter on the revision history. 06:36 < jdl> nod 06:36 < pasky> gittus: hi! 06:36 < jdl> It's all over now. 06:37 * -> pasky is just on his way to bed 06:37 < gittus> I should add a command line flag to "git whatchanged" to allow filtering on the revision history. Sometimes you want to see the whole commit. 06:37 * jdl and pasky are in the same timezone. 06:37 < njs`> hmm, I should probably look more closely at the various git scripting out there 06:37 < njs`> monotone's scripting interface is pretty nice, but definitely hasn't had as much work put into it 06:38 < gittus> njs: as I told Keith Packard, if you grok "git-rev-list" in all its forms, you grok git. Everything else is just scripting around it. 06:38 < jdl> Heh. 06:38 < njs`> yeah 06:38 < jdl> My dog has just come to tell me it is bedtime here too. 06:38 < jdl> gittus Nice talking to you! 06:38 < njs`> we have a decent set of commands for generating and manipulating rev sets, but not quite so much, I think :-) 06:38 < gittus> jdl: l8r 06:39 < jdl> More later! 06:39 < gittus> njs: I think the original git design very much focused me on scripting, so a lot of the whole design of git is all about how to script stuff 06:39 < pasky> jdl: you also go to sleep at 6am? ;) 06:40 < njs`> gittus: yeah 06:41 < njs`> gittus: it makes sense, though monotone's emphasis on providing things out of the box has reduced the amount of day-to-day exercise the scripting stuff gets 06:41 < gittus> It's really funny, though - once you get used to the scriptability, you can generate these insane one-liners 06:41 < gittus> The one I did earlier today: 06:41 < gittus> git-whatchanged | grep '^::' | cut -f2- | sort | uniq -c | sort -n | less -S 06:41 < njs`> hah 06:42 < njs`> that's a nice trick 06:42 < njs`> (sort | uniq -c | sort -n) 06:42 < pasky> now, what _is_ ^:: ? 06:42 < gittus> it makes no sense at all, but it will give you a list of all files in the repo history that have had file-level merging. Sorted by how many times it needed merging. 06:43 < gittus> Basically, git has two "forms" of diffs: regular "patches", and the actual internal git representation. 06:43 < gittus> The 06:43 < gittus> The ':' marker at the beginning of the line is the marker for a raw git diff 06:44 < gittus> When there are two (or more) ':' at the beginning, it marks that the file had two (or more) parents 06:44 < njs`> hmm 06:44 < gittus> So the "grep '^::'" line just picks out the raw diff lines that were the result of a merge. 06:45 < njs`> definitely worth looking at, our canonical form is not very greppable 06:45 < njs`> is this "merge requiring user intervention", "merge whose result differs from both parents", or "merge whose result differs from at least one parent"? 06:46 < gittus> This is "merge whose result differs from any of the parents" 06:46 < gittus> Remember: there may be more than two parents. 06:46 < pasky> gittus: when was that multi-: thing added? 06:47 < gittus> So my command line would not pick up merges that had conflicts, but they resolved to one of the parents 06:47 < gittus> pasky: it's really new. I don't think Junio has even merged my patches yet. 06:47 < gittus> It's a result of the "--cc" flag to git-diff-tree, made more general, so that it now works with the raw format too 06:48 < pasky> ah yes, I thought it would be something like --cc for raw diffs 06:49 < njs`> gittus: oh, right, I'm used to the world where octopi never evolved. 06:49 < gittus> njs: they really aren't anything fundamentally useful, but they make the history look nicer 06:50 < njs`> I guess opinions might differ on that :-) 06:50 < njs`> but it's pretty minor, anyway 06:50 < gittus> It's just a denser way of saying "merge these five trees" 06:50 < gittus> Well, "nicer" is obviously in the eye of the beholder, yes. 06:50 < njs`> oh, here's a really stupid question -- where do I go to learn the details of git's packign heuristics? google avails me not, reading the source didn't help a lot, and wading through the whole mailing list seems less efficient than any of that. 06:51 < pasky> yes, the packing-related delta stuff is somewhat mysterious even for me ;) 06:52 < gittus> njs, I don't think the docs exist. That's something where I don't think anybody else than me even really got involved. Most of the rest of git others have been busy with (especially Junio), but packing nobody touched after I did it. 06:52 < njs`> I guess the next step is "read the source again", but I have to build up a certain level of gumption first :-) 06:52 < gittus> The packing heuristic is actually really really simple. 06:52 < gittus> But strange. 06:52 < gittus> Remember: git really doesn't follow files. So what it does is 06:52 < gittus> - generate a list of all objects 06:52 < gittus> - sort the list according to magic heuristics 06:53 < gittus> - walk the list, using a sliding window, seeing if an object can be diffed against another object in the window 06:53 < njs`> I suspect that what I'm missing is the precise definition of the word "magic" 06:53 < gittus> - write out the list in recency order 06:53 < pasky> yes 06:54 < njs`> oh, hmm, and I'm not sure what this sliding window means either 06:54 < pasky> iirc, it appeared to me to be just the sha1 of the object 06:54 < pasky> when reading the code causually 06:54 < gittus> The "magic" is actually in theory totally arbitrary. ANY order will give you a working pack, but no, it's not ordered by SHA1 06:54 < pasky> which simply doesn't sound as a very good heuristics, though ;) 06:54 < njs`> .....and recency order. okay, I think it's clear I didn't even realize how much I wasn't realizing :-) 06:55 < gittus> Before talking about the ordering for th esliding delta window, let's talk about the recency order. That's more important in one way. 06:55 < njs`> right, but if all you want is a working way to pack things together, you could jsut use cat and save yourself some trouble... 06:55 < gittus> The recency ordering (which is basically: put objects _physically_ into the pack in the order that they are "reachable" ffrom the head) is important 06:56 < njs`> okay 06:56 < gittus> It's important because that's the thing that gives packs good locality. It keeps the objects close to the head (whether they are old or new, but they are _reachable_ from the head) at the head of the pack. So packs actually have absolutely _wonderful_ IO patterns. 06:57 < gittus> But recency ordering is totally useless for deciding how to actually generate the deltas, so the delta ordering is something else. 06:57 < gittus> The delta ordering is (wait for it) 06:58 < gittus> - first sort by the "basename" of the object, as defined by the name the object was _first_ reached through when generating the object list 06:58 < gittus> - within the same basename, sort by size of the object 06:59 < gittus> - but always sort different types separately (commits first) 06:59 < gittus> That's not exactly it, but it's very close. 06:59 < njs`> the "_first_ reached" thing is not too important, just you need some way to break ties since the same objects may be reachable many ways, yes? 07:00 < gittus> Correct. 07:00 < gittus> The point is that it's all really just any random heuristic, and the ordering is totally unimportant for correctness, but it helps a lot of the heuristic gives "clumping" for things that are likely to delta well against each other 07:01 < njs`> and "basename" means something like "the tail of end of path of file objects and dir objects, as per basename(3), and we just declare all commit and tag objects to have the same basename" or something? 07:01 < gittus> I played around with different delta algorithms, and with making the "delta window" bigger, but having too big of a sliding window makes it very expensive to generate the pack: you need to compare every object with a _ton_ of other objects. 07:03 < gittus> There are a number of other trivial heuristics too, which basically boil down to "don't bother even trying to delta this pair" if we can tell before-hand that the delta isn't worth it (due to size differences, where we can take a previous delta result into account to decide that "ok, no point in trying that one, it will be worse") 07:04 < gittus> End result: packign is actally very size efficient. It's somewhat CPU-wasteful, but on the other hand, since you're really only supposed to do it maybe once a month (and you can do it during the night), nobody really seems to care. 07:04 < njs`> so, just to repeat to see if I'm following, we start by getting a list of the objects we want to pack, we sort it by this heuristic (basically lexicographically on the tuple (type, basename, size)) 07:04 < njs`> then we walk through this list, and calculate a delta of each object against the last n (tunable paramater) objects, and pick the smallest of these deltas 07:05 < gittus> Correct. 07:05 < njs`> and then once we have picked a delta or fulltext to represent each object, we re-sort by recency, and write them out in that order. 07:05 < gittus> Yup. Some other small details: 07:05 < gittus> - we limit the delta depth to another magic value (right now both the window and delta depth magic values are just "10") 07:05 < njs`> hrm, my intuition is that you'd end up with really _bad_ IO patterns, because the things you want are near by, but to actually reconstruct them you may have to jump all over in random ways. 07:06 < gittus> - iwhen we write out a delta, and we haven't yet written out the object it is a delta against, we write out the base object first. 07:06 < gittus> And no, when we reconstruct them, we actually get nice IO patterns, because 07:07 < gittus> - larger objects tend to be "more recent" (Linus' law: files grow) 07:07 < gittus> - we actively try to generate deltas from a larger object to a smaller one 07:08 < gittus> - this means that the top-of-tree very seldom has deltas (ie deltas in _practice_ are "backwards deltas") 07:08 < njs`> so the point is just that in practice, delta order and recency order match each other quite well. 07:08 < gittus> Yes. There's another nice side to this (and yes, it was designed that way ;): 07:09 < gittus> - the reason we generate deltas against the larger object is actually a big space saver too! 07:09 < njs`> hmm, but your last comment (if "we haven't yet written out the object it is a delta against, we write out the base object first"), seems like it would make these facts mostly irrelevant 07:09 < njs`> because even if in practice you would not have to wander around much, in fact you just brute-force say that in the cases where you might have to wander, don't do that :-) 07:10 < gittus> Yes and no. Notice the rule: we only write out the base object first if the delta against it was more recent. 07:10 < gittus> That means that you can actually have deltas that refer to a base object that is _not_ close to the delta object, but that only happens when the 07:10 < gittus> delta is needed to generate an _old_ object. 07:10 < gittus> See? 07:11 < gittus> This keeps the front of the pack dense. The front of the pack never contains data that isn't relevant to a "recetn" object. 07:12 < gittus> The size optimization comes from our use of xdelta (but is true for many other delta algorithms): removing data is cheaper (in size) than adding data. 07:13 < gittus> When you remove data, you only need to say "copy bytes n--m". In contrast, in a delta that _adds_ data, you have to say "add these bytes: 'actual data goes here'" 07:14 -!- njs` [n=njs@66.92.218.83] has signed off (Read error: 104 (Connection reset by peer)) 07:15 < gittus> Uhhuh. I hope I didn't blow njs' mind. 07:15 -!- njs` [n=njs@66.92.218.83] has joined #git 07:15 < pasky> :) 07:15 < gittus> njs - did you miss anything? 07:16 < njs`> stupid router. 07:16 < njs`> or gremlins, or whatever. 07:16 < njs`> Yes and no. Notice the rule: we only write out the base object first if the delta against it was more recent. 07:16 < njs`> I'm getting lost in all these orders, let me re-read :-) 07:16 < njs`> so the write-out order is from most recent to least recent? 07:16 < njs`> (conceivably it could be the opposite way too, I'm not sure if we've said) 07:16 < njs`> though my connection back at home is logging, so I can just read what you said there :-) 07:16 < gittus> Yes, we always write out most recent first 07:17 < pasky> njs`: http://pastebin.com/547965 07:17 < njs`> and, yeah, I got the part about deeper-in-history stuff having worse IO characteristics, one sort of doesn't care. 07:17 < gittus> With the caveat that if the "most recent" needs an older object to delta against (hey, shrinking sometimes does happen), we write out the old object with the delta 07:17 < njs`> (if only it happened more...) 07:18 < gittus> Anyway, the pack-file could easily be denser still, but because it's used both for streaming (the git protocol) and for on-disk, it has a few pessimizations 07:19 < gittus> In particular, while the pack-file is then compressed, it's compressed just one object at a time, so the actual compression factor is less 07:20 < gittus> than it could be in theory. But it means that it's all nice random-access with a simple index to do "object name->location in packfile" translation 07:20 < pasky> gittus: just a quick reaction to the backlog I peeked at - cogito doesn't have any separate mailing lists, and junio tends to watch cogito posts for git problems.. otherwise, my hopes are obviously opposite than yours ;) it still seems to me that git's UI is pretty ugly compared to cogito, modulo few cool gadgets 07:20 < njs`> I'm assumign the real win for delta-ing large->small is more homogenous statistics for gzip to run over? 07:20 < njs`> (you have to put the bytes in one place or another, but putting them in a larger blob wins on compression) 07:20 < njs`> actually, what is the compression strategy -- each delta individually gzipped, the whole file gzipped, somewhere in between, no compression at all, ....? 07:21 < njs`> right 07:21 < pasky> I'll read the rest at the morning, I really have to go sleep or there's no hope whatsoever for me at the today's exam... g'nite all 07:22 < gittus> Right: large->small matters exactly because of compression behaviour. If it was non-compressed, it probably wouldn't make any difference 07:22 < njs`> yeah 07:22 < gittus> pasky: g'nite 07:22 < njs`> pasky: 'luck 07:23 < gittus> Anyway: I' 07:24 < gittus> I'm not even trying to claim that the pack-files are perfect, but they do tend to have a nice balance of density vs ease-of use. 07:24 < gittus> More importantly, they allow git to still _conceptually_ never deal with deltas at all, and be a "whole object" store. 07:25 < gittus> Which has some problems (we discussed bad huge-file behaviour on the git lists the other day), but it does mean that the basic git 07:25 < gittus> concepts are really really simple and straightforward. 07:26 < gittus> It's all been quite stable. 07:26 < gittus> Which I think is very much a result of having very simple basic ideas, so that there's never any confusion about what's going on. 07:27 < gittus> Bugs happen, but they are "simple" bugs. And bugs that actually get some object store detail wrong are almost always so obious that they never go anywhere. 07:27 < njs`> yeah 07:28 < njs`> that was always one of the nice things in monotone, that the object store didn't have to care about anyone else, and no-one else had to care about the object store... 07:28 < njs`> we're working on redoing it to reduce some bottlenecks, though, so we've been throwing around all sorts of crazy ideas 07:29 < gittus> Right. A lot of git ends up being just a very special-purpose object database. 07:29 < njs`> IO optimization is tricky, let's go shopping... 07:29 < gittus> The only other "interesting" part of git is how some of the original data layout behaviour caused me to split the "tree" object from one linear one to a recursive one. 07:30 < njs`> the motivation for that was the poor man's delta compression? 07:30 < gittus> I think monotone has the "one linear tree" view (aka "manifest"). And mercurial ended up doing that too. 07:30 < njs`> (that was always what I more-or-less assumed, but not really sure) 07:30 < njs`> yeah 07:31 < gittus> Yes, in the absense of delta compression, the recursive tree format was a great way to only have to rewrite a part of the tree. 07:31 < gittus> However, it actually ends up being nice now. It's great how we can do a "diff" between two trees, and totally just skip subdirectories. 07:31 < njs`> nod 07:32 < gittus> That was "intentional", but it wasn't _why_ the recursive thing was done. And it turns out that it makes some of 07:33 < gittus> the ops a bit more complex to code for (instead of having a flat object, you have to have these recursive reading functions), it does have 07:33 < gittus> lots of upsides. 07:33 < njs`> nod 07:34 < njs`> I kinda like the simplicity we get from just having a single whole-tree object (and the trade-offs are probably a bit different, since monotone's tree objects are more complicated than git's), but we'll see how far we can push that :-) 07:37 < gittus> I don't think th e"single tree" is necessarily a problem. My gut feel is that monotone problems are more with the generic database. 07:37 < gittus> Havign a specialized database just makes things so simple. 07:37 < njs`> hmm 07:37 < njs`> if by problems you mean "the particular speed bottlenecks we have right now", maybe :-) 07:38 < gittus> Well, I obviously never got past the performance problems. I'm sure it's better now, but at the same time, I just wonder.. 07:38 < njs`> but mostly the result of using sqlite is that we haven't spent any time on storage related issues for the last few years, and had lots of time to worry about other things :-) 07:38 < njs`> sure 07:39 < gittus> Somebody was complaining about "git merge" performance a week or so ago. I was actually worried for a while, but the timigns made it clear that 07:39 < njs`> the performance problems you ran into all basically had nothing to do with the db, just basic working copy optimizations that we didn't do until the week after that :-) 07:39 < gittus> th ebiggest part of the cost was actually doing the "diffstat" on the result, and just the fact that he had to update several hundred megs of working tree. 07:40 < njs`> the only operation that's really a problem is doing initial pull, and that was because our sanity checking was too slow 07:40 < gittus> So what about merges? 07:41 < njs`> but we finished rewriting the versioning stuff last month, so now the sanity checking is fast and the storage system seems to be the last bottleneck. 07:41 < gittus> I've been timing my merges (or rather, going back and looking at the date-stamps), and when I merge, I tend to spend 45 seconds per merge. 07:41 < njs`> (and mostly that because we're doing fantastically stupid things with it, we just need to figure out if there's something "fantastically smart", as opposed to "not quite as stupid") 07:42 < njs`> I'm not sure at the moment 07:42 < gittus> And that 45 seconds is not just the network traffic to actually get the new results, but it's the time it takes for me to write "git pull" and copy-and-paste the repository address from an email. 07:42 < njs`> it should be pretty fast, though, all we have to do is load the two trees into memory and then do a single-pass of iteration over them 07:43 < gittus> You seem to be a lot better off than some, then. I think it was darcs (but I might be mis-remembering) that had people saying that 20+ minutes was normal ;) 07:45 < njs`> the new stuff doesn't need to even look at ancestors unless there are conflicts, and there's no rename inference to do either 07:45 < njs`> darcs has some issues; their underlying versioning framework has unsolved theoretical issues :-/ 07:45 < njs`> it's sad, because it can do all sorts of magic that no-one else can, but right now no-one on earth knows if there is a version of it that actually works in the general case. 07:45 < gittus> Anyway. I'm off for bed. It's not 6AM here, but I've got three kids, and have to get up early in the morning to send them off. I need my beauty sleep 07:45 < njs`> :-) 07:46 < njs`> appreciate the infodump, I really was failing to find the details on git packs :-) 07:46 < gittus> Btw, how do you avoid lookin gup the most recent common ancestor? You'd need the origin data just to determine that one branch hadn't touched it? 07:47 < njs`> "magic heuristics" 07:47 < njs`> ;-) 07:47 < gittus> Or do you mean that you don't actually go and bother with the _file_ ancestry, you just see that one file matches the common origin and let it be? 07:47 < njs`> well, without the heuristics 07:47 < njs`> http://revctrl.org/MarkMerge 07:48 < njs`> we need exactly the left tree, the right tree, and a list of revs that are "uncommon ancestors" of each side (which is cheap, because we have a cache of the graph) 07:48 < njs`> it handles criss-cross merge and all that too 07:50 < gittus> Ok. git considers that "looking at the history". And yes, it's cheap in git too. 07:50 < gittus> Now I'm off for bed. Nighty night. 07:50 < njs`> git has a lookaside cache of it, or it's just cheap to traverse the commit objects? 07:50 < njs`> right, sorry. 'night! 07:50 < gittus> It's just cheap to traverse the commit objects. 07:51 < gittus> Actually, it's only cheap because we make sure to never traverse more history than we need to 07:51 < njs`> right, the nice thing about mutual uncommon ancestors is that you can calculate these sets in time ~linear in the number of uncommon ancestors, not the whole graph 07:52 < gittus> But especially with a packed tree, I can actually traverse the whole kernel history in 0.7 seconds (but most ops never need to - they'll just traverse as much of it as they need) 07:52 < gittus> Yes. That's a big deal. git used to generate the whole graph very early on, we got rid of that quickly. 07:53 < gittus> (Git still generates the whole graph for some things: if you want to rewrite history ("history as seen by these files") you need to do it, but that's a special op) 07:53 < gittus> ANYWAY. 07:53 < gittus> I'm off. 07:53 < njs`> right 08:41 -!- Newsome [n=sorenson@216-190-206-130.customer.csolutions.net] has signed off ("Linux: Now with employee pricing!") 09:05 < dmlb2000> jdl: thanks, I appreciate the answer :) problem fixed ;) 09:07 < dmlb2000> git is actually working out quite well sharing filesystems across my network (instead of using nfs) 09:07 < dmlb2000> it's really fast updating and commiting 09:09 -!- njs` [n=njs@66.92.218.83] has signed off (Read error: 110 (Connection timed out)) 09:27 -!- njs` [n=njs@66.92.218.83] has joined #git 11:18 -!- benlau [n=benlau@221.125.13.158] has joined #git 11:19 -!- Tv [n=tv@GMMDXXVII.dsl.saunalahti.fi] has joined #git 12:55 -!- mchehab [n=mchehab@200.101.110.186] has joined #git 12:58 -!- dwmw2_gone is now known as dwmw2 13:58 -!- Oejet [n=s022018@bohr.gbar.dtu.dk] has joined #git 14:21 -!- coywolf [i=coywolf@everest.sosdg.org] has joined #git 14:21 < coywolf> i need git help 14:21 < coywolf> $ git-branch 14:21 < coywolf> v2.6.16-rc1-mm1 14:21 < coywolf> v2.6.16-rc1-mm2 14:21 < coywolf> v2.6.16-rc1-mm3 14:21 < coywolf> v2.6.16-rc1-mm4 14:21 < coywolf> v2.6.16-rc1-mm5 14:21 < coywolf> v2.6.16-rc2-mm1 14:22 < coywolf> how can I know the current branch? and switch to another branch? 14:22 < Oejet> git-branch should write an asterisk in from of the current branch. 14:23 < coywolf> * master 14:23 < coywolf> origin 14:23 < coywolf> v2.6.13-mm1 14:23 < coywolf> v2.6.13-mm2 14:23 < coywolf> v2.6.13-mm3 14:23 < coywolf> i got that 14:23 < coywolf> how can I know what master reaaly is? 14:24 < coywolf> Oejet, 14:24 < Oejet> cat .git/refs/heads/master 14:25 < Oejet> It's probably more informative to run gitk. 14:27 < coywolf> Oejet, i'm in CLI 14:27 < Oejet> git-show-branches 14:29 < pasky> or cg-status -g 14:29 < Oejet> Oh, and git-whatchanged shows you the history from the current head. 14:30 < pasky> or cg-log if you want nicer output ;) 14:50 -!- timlarson_ [n=timlarso@65.116.199.19] has joined #git 15:41 * Tv notes cg-status -g is *the* cogito command I still use. 15:44 -!- Newsome [n=sorenson@obelix.cs.byu.edu] has joined #git 15:55 < jdl> blink 15:56 < jdl> So njs` == Newsome ? 15:58 < Newsome> hmm, no, I don't think so 15:58 < jdl> OK. No problem. 15:59 < jdl> Question for njs: Would you mind if I condensed, edited, wrote up your disussion with gittus over packs, and posted/added it to the Docs as a "starting point" about packs? 16:01 < jdl> dmlb2000: No problem. Let us know if you have other questions too! 16:02 < jdl> coywolf: Did you get answers to your question OK? 16:04 < coywolf> jdl, yeah :) 16:04 < jdl> kewl 17:38 -!- mchehab is now known as mchehab-away 17:46 -!- GyrosGeier [n=richter@82.113.106.0] has joined #git 17:50 -!- Oejet [n=s022018@bohr.gbar.dtu.dk] has signed off ("Download Gaim: http://gaim.sourceforge.net/") 18:29 < GyrosGeier> hrmpf 18:29 < GyrosGeier> AuthReply: I HATE YOU 18:29 < GyrosGeier> what is going on here? 18:30 < GyrosGeier> it appears as if a lot of CVS servers were blocking cvsimport 18:31 -!- mchehab-away [n=mchehab@200.101.110.186] has signed off (Read error: 110 (Connection timed out)) 18:41 < coywolf> git-read-tree: fatal: you need to resolve your current index first 18:41 < coywolf> No merge strategy handled the merge. 18:41 < GyrosGeier> coywolf, you have conflicts 18:41 < GyrosGeier> coywolf, you need to manually merge the conflicting files 18:43 < coywolf> [coywolf@everest ~/linux/smurf]$ git-status | head 18:43 < coywolf> # On branch refs/heads/v2.6.16-rc2-mm1 18:43 < coywolf> # 18:43 < coywolf> # Updated but not checked in: 18:43 < coywolf> # (will commit) 18:43 < coywolf> # 18:43 < coywolf> # modified: arch/i386/kernel/cpu/cpufreq/powernow-k7.c 18:43 < coywolf> # modified: drivers/block/aoe/aoeblk.c 18:43 < coywolf> # modified: drivers/block/aoe/aoechr.c 18:43 < coywolf> # modified: drivers/block/aoe/aoedev.c 18:43 < coywolf> # modified: drivers/block/aoe/aoemain.c 18:47 < coywolf> [coywolf@everest ~/linux/linux-2.6]$ git-status 18:47 < coywolf> nothing to commit 18:47 < coywolf> [coywolf@everest ~/linux/linux-2.6]$ 18:51 < GyrosGeier> hrm 18:51 < coywolf> how to checkout a fresh version? 18:51 < GyrosGeier> I use cg-status usually 18:52 < coywolf> how to get to the place before I run git-checkout 18:52 < coywolf> how to get to the place before I run git-checkout 18:52 < coywolf> [coywolf@everest ~/linux/linux-2.6]$ cg-status 18:52 < coywolf> Heads: 18:52 < coywolf> >master 5bc159e6cb7ca8d173195919ee935885c129011e 18:52 < coywolf> origin 5bc159e6cb7ca8d173195919ee935885c129011e 18:52 < coywolf> [coywolf@everest ~/linux/linux-2.6]$ 18:53 < coywolf> coywolf@everest ~/linux/smurf]$ cg-status | less 18:53 < coywolf> Heads: 18:53 < coywolf> master 9ceb50d9c6d3227bc98f36e1d2368e936fa1a9fd 18:53 < coywolf> origin 9ceb50d9c6d3227bc98f36e1d2368e936fa1a9fd 18:53 < coywolf> v2.6.13-mm1 59a1fe35614c3c937a4e8cb6e4a45f1d05544d9d 18:53 < coywolf> v2.6.13-mm2 e3602088f81f66655ec6c62320d5c56839ffc02b 18:53 < coywolf> v2.6.13-mm3 40c9bb0dfc9d8d65271d15aececd0b3e576a9a85 18:53 < coywolf> v2.6.13-rc2-mm1 b937742c79df4e175d4e9fc416d546c426aaca62 18:53 < coywolf> v2.6.13-rc2-mm2 4a0c531abb39dadce4837a8e9c29ae013fd8b4c5 18:53 < coywolf> v2.6.13-rc3-mm1 456fec308e32055676656ca549fef8faffe6f805 18:53 < coywolf> v2.6.13-rc3-mm2 eefccf73f82b2bdf353cd05b8e5d6142210bc80f 18:53 < coywolf> v2.6.13-rc3-mm3 5999a8dcf0e4f541bf1344f965bbdf0d87b6d237 18:53 < coywolf> v2.6.13-rc4-mm1 05230bd16821e2ec80321d72e97e7a2b1a07c6f2 18:53 < coywolf> v2.6.13-rc5-mm1 2f67bd35204664da88251f0f9ba6ae223c298ad0 18:53 < coywolf> v2.6.13-rc6-mm1 53c5e273d690a0e4ed1ff91bf4f70dd60167e35c 18:53 < coywolf> v2.6.13-rc6-mm2 140f40d61d8a9d426d70e3cd993cb716103d1360 18:53 < coywolf> v2.6.14-rc1-mm1 0d3c45dc7b243ae708e15d18e4da67514ab7258d 18:53 < coywolf> v2.6.14-rc2-mm1 0e372800589448d6ceecabd76eba6ffb93fd9faa 18:53 < coywolf> v2.6.14-rc2-mm2 9d34b85e8c5b98b5d83baa929d39f1bcd1e52d96 18:53 < coywolf> v2.6.14-rc4-mm1 656390b350627ca5cd193ceb0811c5d590172a68 18:53 < coywolf> v2.6.14-rc5-mm1 17f0aae623c5e81e45bddef9ed2ea9e58a3b9886 18:54 < coywolf> v2.6.15-mm1 27d98dd086c9d1af7f926ebd4434aaf086da7c15 18:54 < coywolf> v2.6.15-mm2 9ecb3aa7779091d68b4c5eb92ed02ca281b63a69 18:54 < coywolf> v2.6.15-mm3 9ceb50d9c6d3227bc98f36e1d2368e936fa1a9fd 18:54 < coywolf> v2.6.16-rc1-mm1 3298b127bbacf19722c97884970628772c4b2f4d 18:54 < coywolf> v2.6.16-rc1-mm2 2c92f4d239f5d82652b8ff8b86b8725392922355 18:54 < coywolf> v2.6.16-rc1-mm3 514cf6564c0ae16bf37b62f19ee3ac9be76f2f38 18:54 < coywolf> v2.6.16-rc1-mm4 38099aefa5e97d4796cd62d7ce7924ad3b357481 18:54 < coywolf> v2.6.16-rc1-mm5 7636aede31e9a85c07aa7d1090224c403635d293 18:54 < coywolf> >v2.6.16-rc2-mm1 67b9fe6dd46a2b01714cffa49ad0019f9c89e835 18:54 < coywolf> so, the current is v2.6.16-rc2-mm1, but I need to go back to master or origin 19:02 < njs`> jdl: certainly not 19:03 < njs`> jdl: I'm not sure how licensing on conversaionts works, but feel free to call my part MIT licensed (and relicense as allowed by that) 19:04 < gittus> coywolf: just do "git checkout master" 19:04 < coywolf> [coywolf@everest ~/linux/smurf]$ git-checkout master 19:04 < coywolf> fatal: Entry 'Documentation/feature-removal-schedule.txt' not uptodate. Cannot merge. 19:04 < gittus> coywolf: although since you seem to have dirty state, that may not work (you've done work, and git wants you to save the work) 19:04 < coywolf> gittus, ^ 19:05 < gittus> So you have two choices: 19:05 < coywolf> gittus, i want to forget all the dirty work 19:05 < gittus> - throw away your work, and use "git checkout -f master" 19:05 < coywolf> ok 19:05 < gittus> - save the dirty work somehow (by creating a temporary branch, and committing on it) and then just do "git checkout master" 19:06 < coywolf> when I do a git-pull, what branch is it pulling? 19:06 < gittus> "git pull" is conceptually exactly the same as "fetch other branch" + "merge the fetched result into current branch" 19:06 < coywolf> from 19:07 -!- benlau [n=benlau@221.125.13.158] has signed off ("Bye~") 19:07 < gittus> So if you are in branch "v2.6.16-rc2-mm", and you do "git pull origin", you will first fetch origin (whatever that happens to be - my tree, somebody elses tree, whatever) 19:07 < coywolf> so 19:07 < coywolf> 1) git-pull git://some_url 19:08 < gittus> then, after you've fetched that other tree, it will try to merge it into whatever branch you are in now. 19:08 < coywolf> 2) git-checkout 19:08 < coywolf> 3) git-pull git://some_url 19:08 < coywolf> now things messy? 19:08 < gittus> Coywolf: yes, now things messy. 19:08 < gittus> You've done _two_ merges. 19:08 < gittus> Into different branches 19:09 < gittus> Now, one of the branches might have been tracking the thing you "pulled" already, so it may not have been a real merge 19:09 < gittus> If the thing you pull is strictly a superset (from a history standpoint) of the state you already have in a branch, then a "pull" ends up not needing to merge at all 19:10 < gittus> In that case it just "fast forwards" the history 19:10 < gittus> In general, try doing "gitk --all", which shows the combined history of _all_ your branches 19:10 < gittus> (Word of warning: kernel development trees have so much work going on all the time that "gitk --all" is sometimes very hard to understand) 19:11 < gittus> It is probably a good idea to try learning git on a project that isn't quite as complex and active as the kernel. 19:12 -!- Newsome [n=sorenson@obelix.cs.byu.edu] has left #git ("Linux: Now with special employee pricing!") 19:12 < coywolf> gittus, after git-checkout -f, still messy 19:12 < GyrosGeier> and I still wonder what's the canonical way to switch heads with cogito 19:19 < coywolf> gittus, http://lkml.org/lkml/2006/2/10/256/ 20:07 -!- juvenis- [n=juvenis@ASt-Lambert-152-1-6-187.w82-124.abo.wanadoo.fr] has joined #git 20:11 < gittus> coywolf: what do you mean "messed up"? 20:13 < gittus> The master branch seems to point to the same thing as "v2.6.15-mm3" 20:13 < gittus> That may be a bit strange, but the whole git tree by smurf is a bit strange 20:14 < gittus> For example, normally you'd not create a "branch" for a particular state, you'd create a "tag" to it 20:14 < gittus> A "branch" is something you do development on, but a particular state (like a particular -mm release) is 20:14 < gittus> obviously some static point in time. 20:15 < gittus> So I agree that that git tree is confusing. 20:15 < gittus> The way I would have done it, I'd have made all the "v2.6.16-rc2-mm1" things tags, and had just one "master" branch 20:16 < gittus> Then, you can always just do "git checkout -b mybranch v2.6.16-rc2-mm1" to create your own branch at the point that is v2.6.16-rc2-mm1 20:17 < gittus> (Alternatively, you could just do "git reset --hard v2.6.16-rc2-mm1" to just force the "master" branch to a particular 20:17 < pasky> GyrosGeier: cg-switch 20:17 * -> pasky reminds himself to finally release 0.17 20:17 < gittus> version, and that works fine if you just want to look at the state at different points) 20:17 < pasky> fonseca: ping? 20:17 < GyrosGeier> pasky, hrm 20:17 < GyrosGeier> pasky, that's too easy 20:18 < GyrosGeier> pasky, thanks 20:21 < fonseca> pasky: Yes? 20:22 -!- Oejet [n=Eileen_2@0x50a6b7df.bynxx14.adsl-dhcp.tele.dk] has joined #git 20:22 < pasky> fonseca: oh, you sent updated patches, right? 20:23 < pasky> sorry for bothering you, will scan my mailbox 20:23 < Oejet> Good evening pasky and fonseca. 20:23 < fonseca> pasky: The mkpatch thing? 20:23 -!- juvenis-- [n=juvenis@ASt-Lambert-152-1-38-28.w82-124.abo.wanadoo.fr] has signed off (Read error: 110 (Connection timed out)) 20:23 < fonseca> Oejet: Hello. 20:24 < fonseca> pasky: I hope to soon have some auto generated bash completion thing ready. 20:24 < fonseca> pasky: By scanning for optparse in the scripts. 20:25 < pasky> Oejet: good evening to you :) 20:25 < Oejet> fonseca: How's life at DIKU at the moment? 20:25 < pasky> fonseca: I meant the cg-object-id vs revparse 20:26 < fonseca> Oejet: It's ok. They just bought some new robots, a sensor network will be up soon. 20:26 < fonseca> Oejet: An old student? 20:26 < pasky> gittus: http://pasky.or.cz/~pasky/cp/%23git.tar.bz2, just for you ;) 20:26 < pasky> some late night reading stuff 20:27 < fonseca> pasky: I haven't touched that in a long time. 20:28 < pasky> fonseca: hmm.. I have a mental note to finish something with you and it was the only dependency for 0.17 :) 20:28 < pasky> lemme dig the logs 20:31 < Oejet> fonseca: Sort of. I wandered the math and physics departments for a couple of years, and I know some of the dataology students from 2000. 20:31 < fonseca> I started in 2000, in 2001 they introduced "full-time" datalogi. 20:33 -!- timlarson_ [n=timlarso@65.116.199.19] has signed off ("Leaving") 20:33 < fonseca> It is a little sad when you hear about all the cool things going on at DTU, or even the new ITU, (which DIKU is supposed to become a neighbour to). 20:33 < fonseca> But I like that DIKU is such a small place. 20:35 < pasky> fonseca: yes, I've found it! why do you call git-rev-parse --until first and try date if it's now (that's a race between date +%s and git-rev-parse) - why don't you try date first and then pass either its output or the original string to git-rev-parse --until ? 20:36 < Oejet> Well, you can take courses at DTU. I know that Christian (with dark, curly hair and glasses) took a course about error correcting codes there. 20:37 -!- timlarson_ [n=timlarso@65.116.199.19] has joined #git 20:38 < fonseca> pasky: Ah, the date thing. git-rev-parse defaults to 'now' if the date string doesn't make sense. 20:40 < fonseca> pasky: Using date first sounds good. I don't know why to use git-rev-parse --until other than it's convinient and lazy parsing. 20:49 < coywolf> gittus, are you Linus? didn't realiase that 20:49 < coywolf> realise 20:50 -!- mchehab [n=mchehab@200.101.110.186] has joined #git 20:52 < Oejet> Hello, gittus. 20:55 -!- sj` [i=sj@phalse.2600.COM] has joined #git 20:59 < coywolf> Oejet, is he Linus? 21:00 < gittus> coywolf: yup. 21:00 < Oejet> coywolf: I don't know, maybe he's a dog? 21:00 < sj`> hi guys. 21:02 < coywolf> nice 21:04 * Oejet pricks gittus to see how fluffy he is. 21:06 < coywolf> Oejet, next time, i'd ask gittus kernel questions 21:08 * coywolf > bed 21:10 < coywolf> if I forced the master branch be v2.6.16-rc2-mm1 by git-reset, will git-pull work correctly? gittus 21:11 < coywolf> the local master is v2.6.16-rc2-mm1 21:12 < coywolf> what git-pull to fetch? v2.6.15-mm3 or v2.6.16-rc2-mm1? 21:13 -!- coywolf_ [i=coywolf@everest.sosdg.org] has joined #git 21:13 -!- coywolf is now known as coywolf^ 21:14 -!- coywolf_ is now known as coywolf 21:16 -!- coywolf^ [i=coywolf@everest.sosdg.org] has signed off ("Leaving") 21:17 -!- Newsome [n=sorenson@216-190-206-130.customer.csolutions.net] has joined #git 21:24 < pasky> sj`: hi 21:24 -!- Irssi: #git: Total of 32 nicks [0 ops, 0 halfops, 0 voices, 32 normal] 21:26 < Oejet> gittus: Have you ever been in Denmark? 21:27 < Oejet> sj`: Hello. 21:29 < pasky> Oejet: and, cs is _not_ the language code for russian ;) 21:30 < Oejet> pasky: I know, I know, sigh. :) 21:31 < pasky> they are now going to stick you at the czech equivalent of bash.org 21:31 < Oejet> I'm honored. :-P 21:33 < pasky> gittus: it's somewhat annoying that - nor _ is permitted in names of configuration variables 21:45 < CIA-11> pasky * raadea4184373 /cg-commit: Do not run the post-commit hook for all merged commits 21:46 < CIA-11> pasky * r2f676f0c7911 /cg-restore: Merge with v0.16 21:47 < CIA-11> pasky * rfd0c1a6d45ec /cg-commit: Fix the commitmsg empty line pre-inserting 21:50 < CIA-11> proski * re0ca294a4b9b /t/t9000-init.sh: [PATCH] Fix t9000-init.sh - comment for initial commit is different 21:55 < CIA-11> fonseca * rc0f5aeb6d80a / (cg-Xlib cg-commit): [PATCH 1/3] cg-commit: Move author picking to cg-Xlib 21:56 < CIA-11> fonseca * rafbc0abde26e /cg-patch: [PATCH 2/3] cg-patch: Use optparse 21:58 < CIA-11> fonseca * r1ac7157c7f90 /cg-patch: [PATCH 3/3] cg-patch: Add -d option to apply patch directory 21:58 -!- mchehab [n=mchehab@200.101.110.186] has signed off (Read error: 110 (Connection timed out)) 22:01 < pasky> pg looks nice 22:02 < pasky> but it's unclonable :) 22:12 < dormando> hmm... has cogito changed its merge strategy at all yet? 22:13 < dormando> I have a local patch to make it work more like subversion, but I can't turn it into a tunable because of how cgX-mergefile works :\ 22:14 < dormando> debating putting more work on the patch or not 22:19 < pasky> dormando: cogito is still single-strategy; it will change, but probably not very soon 22:19 < pasky> dormando: OTOH your patch mgiht be as good a reason to change it as any 22:19 < pasky> I mean, to add multi-strategy support 22:19 < pasky> dormando: what does "more like subversion" mean? 22:23 < CIA-11> fonseca * rdd0e7423d032 /cg-status: Explain why cg-status can show a file as both deleted and untracked 22:23 -!- Tv [n=tv@GMMDXXVII.dsl.saunalahti.fi] has signed off ("foo") 22:25 -!- timlarson_ [n=timlarso@65.116.199.19] has signed off (Read error: 131 (Connection reset by peer)) 22:25 < dormando> pasky; Something outside of the actual merge strategy, but ugly. They were used to getting the <<<< >>>> file, and a "filename.mine", "filename.theirs" dump so they can manually merge it with their editor of choice 22:25 < dormando> pasky; So all this does is re-get the original file and their own file, then drop it out in front of them 22:25 -!- timlarson_ [n=timlarso@65.116.199.19] has joined #git 22:26 < dormando> pasky; This also makes binary conflicts a lot easier to deal with. 22:26 < dormando> pasky; I think there's a better git-friendly approach, I just haven't had time to work on the patch. 22:27 -!- timlarson_ [n=timlarso@65.116.199.19] has signed off (Client Quit) 22:27 < pasky> dormando: one possible approach could be to introduce configuration variable cogito.merge.conflicts which would say what to do 22:28 < pasky> it'd be also the simples 22:28 < pasky> t 22:28 < dormando> pasky; That's what I was leaning towards. 22:29 < pasky> leaning torvalds.. what a codename! ;) 22:29 * -> pasky hides 22:30 < dormando> ... :P 22:30 < dormando> Alright, I'll go back to lurking unless I have a patch ready 22:30 < dormando> or if you want to make multiple merge strategies available in cogito ;) 22:33 -!- jzlee [n=jzlee@h-66-134-95-38.snvacaid.covad.net] has joined #git 22:33 -!- jzlee is now known as pTwTq 22:33 -!- pTwTq is now known as TwT 22:33 -!- TwT is now known as pTwTq 22:39 < pasky> dormando: well i probably won't get to it myself for some time 22:39 < dormando> pasky; fair enough 22:48 < pasky> but you are obviously welcome to do all the work yourself :)) 22:52 < dormando> I can try :P 22:53 < pasky> fonseca: also, I'm not sure now - did you say you intend to follow up with some new revision of --review or am I all confused again? (I think I'm just imagining things, but want to confirm before I'll start to backport it) 22:59 < CIA-11> pasky * r2ad678478d9d /cg-Xlib: Ensure non-empty $GIT_AUTHOR_NAME when parsing /^author 23:09 < fonseca> pasky: I don't intend to right now. 23:11 < pasky> 'k 23:19 < CIA-11> pasky * rd0a04c90b32d /cg-patch: Be more permissive in cg-patch -d 23:27 < CIA-11> pasky * rbe45153eb523 /cg-patch: Make cg-patch return error on conflicts 23:28 -!- GyrosGeier [n=richter@82.113.106.0] has signed off ("going home") 23:52 -!- Oejet [n=Eileen_2@0x50a6b7df.bynxx14.adsl-dhcp.tele.dk] has left #git () 23:53 < CIA-11> pasky * r1cedab9a92b1 / (TODO cg-patch): 23:53 < pasky> eek 23:58 < pasky> git-rev-parse is evil, won't run if HEAD is empty :) --- Log closed Sat Feb 11 00:00:52 2006