| 2007-03-11 |
| → z3ro joined | 00:58 |
|
| gitte starts to hate the fact that we started coding before thinking through the bundle thing. | 01:10 |
| → z3ro_ joined | 01:15 |
|
| gitte means yours truly by "we". | 01:24 |
| → spearce joined | 01:37 |
|
spearce
| robinr: finish that import yet? ;-) | 01:37 |
| → z3ro joined | 01:38 |
|
spearce
| gitte: what's wrong with the bundle thing? | 01:41 |
|
gitte
| spearce: what is the intent of a bundle? | 01:55 |
| → PugMajere joined | 01:55 |
|
spearce
| gitte: sneakernet a collection of objects from one repository to another. | 01:55 |
|
gitte
| If it is a sneakernet replacement for a fetch, it should _only_ do that. | 01:55 |
|
spearce
| is it now cleaning up your messy pots after supper? | 01:55 |
|
gitte
| I.e. if you want to get the refs "alfa", "beta" and "gamma", the bundle should contain _only_ these. | 01:56 |
|
| Dependency checking is a mess otherwise. | 01:56 |
|
| And I mean a _real_ mess. | 01:56 |
|
| But now, people start to want to include _all_ refs into the bundle! | 01:56 |
|
spearce
| you mean asserting that all parent commits appear in the local repository or are available from the bundle? | 01:57 |
|
gitte
| reachable commits, yes. | 01:57 |
|
| When I started to write builtin-bundle, I thought it would be _only_ a sneakernet (or mailnet) replacement for fetch. | 01:58 |
|
spearce
| gitte: sneakernet sucks. why not just verify every commit in the path? meaning I have some bundle "today.bdl" and I do "git fetch today.bdl master:origin/master". so we verify every commit in today.bdl's master ref back until we have all of them in the bundle or in the local repository. its expensive, but its valid... | 01:58 |
|
gitte
| And I wanted to show how easy -- and robust -- it is to make it a builtin instead of some stupid shell script. | 01:59 |
|
| spearce: What happens if the pack in the bundle is thin? Then you can die() on a partial object, without the chance to say anything which makes sense to a user. | 02:00 |
|
| At least that is what I am expecting (I am not aware if Git would really die() in such a case). | 02:00 |
|
spearce
| gitte: a thin bundle would mean the object's delta base isn't found. that must means you can't index the packfile because you are missing an object. you can't say much at that point, you're f'd. so maybe thin in this application is a bad idea. | 02:01 |
|
| yea, i know, i agreed with gitster and said thin. ;-) | 02:01 |
|
gitte
| It seems to me that what people want to turn into is not sensible: partial repos. | 02:03 |
|
spearce
| as in the bundle behaves like a partial repo? | 02:03 |
| → gitte joined | 02:03 |
|
gitte
| It is more like people want to have a one-file bare shallow repo | 02:04 |
|
spearce
| i think its a nice mental picture. but we're trying to hard to make it really optimal and user friendly in the first implementation of it. | 02:05 |
|
| hmm.. how do thin packs really get created... i wonder... | 02:06 |
|
gitster
| interesting. I was thinking about the same thing. bundle could be a static, shallow proxy of the real repository. | 02:07 |
|
gitte
| spearce: I think they are created like normal packs, only that they allow deltification against objects which are not in that pack. | 02:08 |
|
rlb
| If you want to have one public repo with devel branches for foo-1 and foo-2, but you want to work in separate local working dirs, one for each branch, then is it better to have both working dirs be clones of the public repo, or is it PK if one of the working dirs is cloned from the other, and you fetch back and forth between them, and push to the public dir from either as needed? | 02:08 |
|
gitster
| rlb: does not matter. either model would equally work well. | 02:09 |
|
spearce
| gitte: i know, but i was wondering, can we know what commit found one of those non-packed delta bases? because then we could embed data about that commit in the header of the bundle as "prereq" for the missing delta base so users get a better error message when index-pack can't fix the thin pack in the bundle. | 02:09 |
|
| gitster: while i got you, i'm applying peff's fast-import changes here and testing them, i'll push to gfi in a bit when i'm happy with them. | 02:09 |
|
gitster
| ok. | 02:10 |
|
gitte
| spearce: that was what I was alluding to in my 28-16 argument on the list. | 02:11 |
|
| We _can_ find out what boundaries are reachable from which ref. | 02:11 |
|
| It is either _expensive_, or is "added-on". | 02:12 |
| → Ken joined | 02:13 |
|
spearce
| gitte: here is my (maybe horribly simple?!) take on a bundle: the packing user gives us a set of commits they want to pack into the bundle, and a set of {commit ref} pairs that we will use to name a subset of those commits with. (never mind the age selection issue in rev-list). | 02:13 |
|
gitte
| Yes, we could resurrect the object-hash code, and then _only_ store the reachability for the commits currently in revs->commits. | 02:13 |
|
spearce
| gitte: when we want to fetch from that bundle, we index-pack it to get a workable packfile we can run against. then we parse every commit from the ref we want to "fetch" back through its parents, making sure the commits are complete (see builtin-reflog.c for example of this). | 02:14 |
|
| if anything is missing in that, barf, and try our best at telling the user what's missing. | 02:14 |
|
| f' the prereqs. | 02:14 |
|
matled
| is there any reason the git-gui credits-gen is not as graceful as the normal git-version-gen script? | 02:14 |
|
spearce
| matled: i'm a moron. | 02:14 |
|
matled
| it's annoying | 02:15 |
|
spearce
| yea, i've reached that conclusion to. | 02:15 |
|
gitte
| spearce: It feels wrong to just f' the prereqs. | 02:15 |
|
spearce
| i have to do a bug fix in git-gui for something else; i'll try to make it less annoying and then ask gitster to pull that in. | 02:15 |
|
gitte
| And usually if something feels wrong, it _is_ wrong. | 02:16 |
|
spearce
| gitte: but i think it simplifies the entire thing. we literally can treat the bundle as a bare repository then. | 02:16 |
|
| matled: usually i do "make dist" to get a tarball of git.git that i can compile elsewhere. that makes the credits gen slightly less annoying. | 02:16 |
|
gitster
| how about allowing only explicit positive and negative refs on the command line of "bundle create"? Then what it means should be very clear and there won't be any confusion. | 02:16 |
|
gitte
| spearce: but it means that a "git fetch x.bundle" can takes a _long_ time, only to fail with a less-than-useful message. | 02:17 |
|
matled
| spearce: my fix was http://rafb.net/p/ESmGWj89.html | 02:17 |
|
spearce
| gitte: not that long. indexing the packfile then doing the reachability check isn't that bad. its sneakernet! its slow anyway! | 02:17 |
|
gitster
| question. with the recent change to keep pushed or fetched objects in the pack, is it not unusual to have 70 packs in your working repository? | 02:18 |
|
gitte
| spearce: but you don't sit on your hands while waiting for the mail. You _do_ wait for the fetch to complete. | 02:18 |
|
| gitster: until you do "git gc"... | 02:18 |
|
spearce
| gitster: yes; but i usually get around to a git-gc before it breaks 20 packs. | 02:18 |
|
gitster
| Is it a useful improvement if git operation in such a repository that used to take 5.30 seconds now take 4.40 seconds, or is it in the noise? | 02:19 |
|
clee
| gitster: that's more than +/- 5% | 02:19 |
|
| gitster: is it reproducible? | 02:19 |
|
spearce
| gitster: might be useful if the operation is frequent enough. ;-) | 02:19 |
|
gitte
| gitster: I tried to argue for explicit positive and negative refs, but then you suggested "master ^master" to mean "master ^master^{1-infinity}" | 02:19 |
|
gitster
| I do not think "master ^master" means that... | 02:19 |
|
| "master ^master" means do not put any object in pack because of these ref pairs. | 02:20 |
|
raalkml
| btw, does master~ mean something? | 02:20 |
|
gitster
| raalkml: see the comment in sha1_name.c. | 02:20 |
|
gitte
| gitster: yes, you are right. | 02:20 |
|
gitster
| what I suggested was (dubious)... | 02:20 |
|
| at the same time, bundle could say "by the way, master is at this commit". | 02:21 |
|
gitte
| gitster: it added all the known refs which were not really included in the pack prerequisites. | 02:21 |
|
gitster
| But that automatically means making master a prereq, which was iffy. | 02:21 |
|
gitte
| s/prereq/as prereq/ | 02:21 |
|
gitster
| however. if we keep prereq list _per_ listed head (in the above example, if you want to "fetch" that master, you need to have it itself), then I suspect it may be workable. | 02:22 |
|
gitte
| BTW how would you define the header syntax for per-ref prereqs? | 02:22 |
|
gitster
| So bundle list-head would say master is at X and next is at Y. | 02:22 |
|
raalkml
| gitster: right. Can be mentioned in the manpage of rev-parse | 02:22 |
|
spearce
| gitte: actually we don't need to do the full reachability analysis of a tree. just the commits in the commit chain of what you are about to fetch. that's pretty quick, even on a large-ish bundle fetch. | 02:23 |
|
gitster
| and also if you want to use master you need to have Z but to use next you need something else. | 02:23 |
|
| gitte goes and looks what happens with incomplete objects from thin packs. | 02:23 |
|
gitster
| unpack-object dies with "base object not found". I do not know offhand what index-pack does. | 02:24 |
|
gitte
| Seems like fix_unresolved_deltas() in index-pack returns void. | 02:24 |
|
| So there is no chance it errors out gracefully if an incomplete object was found. | 02:25 |
|
gitster
| sheesh. | 02:25 |
|
spearce
| oooh. i just caught up with you two. wow. :) | 02:25 |
|
gitte
| Worse: if branch "A" _and_ branch "B" are contained in one bundle, and you want only "A" _and_ have all the prereqs for it, but not for "B" (which you don't care about), you cannot fetch because the pack contains incomplete objects. | 02:25 |
|
spearce
| gitte: yea, that's what i just realized too. messy. | 02:26 |
|
| gitster answers clee and spearce: yes it is reproducible and very frequent operation, as I am optimizing code to read objects from packs, it applies to everything. | 02:26 |
| → gitte joined | 02:26 |
|
gitte
| See why I get so unhappy about the course we are heading with bundles? | 02:26 |
|
spearce
| gitster: i'd love to at least see the code, because my pack v4 topic is in the same section. ;-) | 02:27 |
|
gitster
| Ok. Now what's the corrected course? | 02:27 |
|
| spearce: probably not. You would barf to see how simple it is if you see the code, actually. | 02:27 |
|
clee
| gitster: then it's definitely a useful improvement | 02:27 |
|
spearce
| gitster: simplicity rules. :-) | 02:27 |
|
gitster
| I am just sorting the packed_git linked list at the end of prepare_packed_git, so that younger packs and local packs are searched first. | 02:28 |
|
gitte
| gitster: I'd say: only send bundles with _exactly_ the refs you are expecting the other side to update. | 02:28 |
|
spearce
| gitster: hah! its also not a section i touched with pack v4. nice. put it in! ;-) | 02:28 |
|
| gitte: that or abandon the thin idea. | 02:29 |
|
| clee has been reading Practical File System Design | 02:30 |
|
clee
| by the guy who did BFS | 02:30 |
|
| pretty awesome book. | 02:30 |
|
gitte
| spearce: we could clean up index-pack (possibly with --skip-incomplete) to ignore incomplete objects. | 02:31 |
|
gitster
| I initially was hoping that prepackaged set of bundles could help dumb transports (perhaps we would make a single "manifest file" of bundles heads and prereqs), and that was why I preferred the "mini proxy shallow repo". | 02:31 |
|
spearce
| gitte: then you have to do full reachability, or something, to make sure the commits are complete there... and you didn't skip the blobs it uses. | 02:31 |
|
gitster
| But sneakernet and e-mail to specific recipient is simpler and cleaner definition of what it should be. | 02:32 |
|
gitte
| But that would still not handle the case where branch "A" contains an object "X" which is deltified against object "Y" contained in branch "B", which is in turn deltified against an object which is not in "A". | 02:32 |
|
gitster
| this might be totally whacky approach, but I wonder if we can treat multiple positive refs more or less independently. | 02:33 |
|
spearce
| gitte: which is why you need to do the full reachability as soon as you allow a "--skip-incomplete" type of behavior. and then you get weird transient failures, just because of the way the pack was built. bad user experience. | 02:33 |
|
gitte
| Maybe we should make the pack thin only in the case of _one_ positive ref. | 02:34 |
|
gitster
| or only when there is one boundary? | 02:35 |
|
| gitte has the impression that the simple, elegant and obviously correct thing was not yet spelt out. | 02:36 |
|
gitte
| gitster: yes, that sounds sensible: if (nr_positive == 1 || nr_negative == 1) thin = 1 | 02:37 |
|
spearce
| gitte: --reverse rocks. very nice to have. :) | 02:37 |
|
gitte
| And maybe we should do the reachability check after unbundle _anyway_. | 02:37 |
|
| spearce: :-) | 02:38 |
|
gitster
| what did you use it for? | 02:38 |
|
spearce
| --reverse? `git log -p --reverse alt/maint..` to see peff's changes, in series order. | 02:38 |
|
| i find it much easier to read then the normal newest->oldest progression when reviewing a series. | 02:39 |
|
gitster
| Ah, I see. I do format-patch --stdout | less ;-) | 02:39 |
|
spearce
| not `-p format-patch --stdout` ? | 02:39 |
|
gitte
| git config alias.fp "-p format-patch --stdout" | 02:40 |
|
spearce
| ah, yea, i should do that. but my fingers get log --reverse faster. and i have a script already called 'fp' that i use to send patch series to Junio+git@vger... ;) | 02:41 |
| Ken → signified | 02:41 |
| ← signified left | 02:42 |
| → GeertB joined | 02:44 |
|
gitte
| To sum the bundle thing up: I am thinking about making the pack thin only when exactly one positive, or less than two negative prereqs were given, and to check reachability after unbundling, before updating the ref. | 02:44 |
|
| I'll think about it more after I slept a couple hours, though. 'night. | 02:45 |
| → bfields joined | 02:53 |
|
spearce
| gitster: still around? i can't decide if peff's gfi patches should go into maint or master... | 03:07 |
|
rlb
| (So I suppose if you have two working trees normally on 2 different branches and then a public repo with both branches, it's up to you to make sure that you push/pull between all three enough to keep them in sync... I suppose that makes sense.) | 03:13 |
|
spearce
| rlb: yes | 03:13 |
|
rlb
| So to create the foo-2.0 branch, I suppose I could just clone from the working tree for foo-1.0, which would leave the new tree on foo-1.0, and then "git branch foo-2.0". | 03:14 |
|
| Does it make any difference whether both of the working dirs are clones of a common repo or whether one working dir is a clone of the other with respect to various defaults? i.e. I'm wondering about things like origin, etc. | 03:16 |
|
spearce
| that would make the branch foo-2.0, but it wouldn't switch to it or anything. | 03:16 |
|
rlb
| spearce: right, then I'd need to "git checkout foo-2.0" in the foo-2.0 working dir. | 03:16 |
|
spearce
| yes, if the defaults are different; we default origin to the repository we cloned from. | 03:16 |
|
rlb
| spearce: is that a permanent difference somehow, or can I always just edit those files? | 03:17 |
|
| i.e. I just noticed that the origins stuff now shows up in gitk --all in the cloned tree. | 03:17 |
|
spearce
| rlb: its just in .git/config, you can hand edit it. | 03:17 |
|
| then run git fetch; git remote prune origin; to correct everything out if you want to fix the branches. | 03:18 |
|
| (sorry, fix the *remote* branches) | 03:18 |
|
rlb
| Hmm, maybe I'd rather have one local "common" repo, and have both working dirs fetch/push from/to that, and then push from the common repo to the public repo... Is that a sane arrangement? | 03:19 |
|
| It seems like it might be more symmetric and/or easier to keep track of. | 03:19 |
|
spearce
| rlb: it is, that's what i do most of the time. | 03:20 |
|
rlb
| spearce: ok, thanks again. | 03:20 |
| → GeertB joined | 03:35 |
| → lu_zero joined | 04:47 |
| → z3ro joined | 05:07 |
| → rkaway joined | 05:28 |
| → rkrush joined | 05:30 |
| → benlau joined | 05:35 |
| → orospakr joined | 05:41 |
| → z3ro_ joined | 06:27 |
| → kanru joined | 08:16 |
| → Eludias joined | 08:30 |
|
mugwump
| fatal: remote part of refspec is not a valid name in refs/heads/*:refs/heads/* | 09:21 |
|
| during "git-push" | 09:21 |
|
| config line is: push = refs/heads/*:refs/heads/* | 09:21 |
| → rhican joined | 09:55 |
|
rhican
| i keep getting "error: Can't lock ref parent", on a git clone | 10:01 |
|
| anything i can do to fix that? is there a command that will just checkout the head? (i'm a bit lost in the docs right now) | 10:02 |
| → nud_ joined | 10:16 |
| → Romster joined | 10:29 |
| → chris2 joined | 10:50 |
| → raalkml joined | 11:08 |
|
robinr
| rhican: git checkout <name of branch> | 11:09 |
|
| otoh, the error is odd. Does your repo have a master branch? | 11:10 |
|
rhican
| robinr, i don't have the git repository yet, | 11:10 |
|
robinr
| I'm thinking of the one you want to clone | 11:11 |
|
rhican
| well it's not my repo, i'm not really familiar with git | 11:11 |
|
| its this command that fails for me: git clone http://intellinuxwireless.org/repos/iwlwifi.git | 11:11 |
| → lhz joined | 11:18 |
|
rhican
| if that's me being completely retarded feel free to let me know ;) | 11:19 |
|
raalkml
| rhican: just cloned it, no problem | 11:21 |
|
| with your command | 11:21 |
|
rhican
| raalkml, what version of git? | 11:22 |
|
raalkml
| 1.5.0.3+ | 11:22 |
|
rhican
| i'm going to try upgrading then | 11:22 |
|
raalkml
| what was the error, though? I missed it | 11:23 |
|
rhican
| "error: Can't lock ref parent" | 11:23 |
|
raalkml
| hmm... MacOSX or windows? | 11:23 |
|
rhican
| gentoo linux | 11:23 |
|
raalkml
| hmmm.... NFS, maybe? | 11:24 |
|
| no write permission in the directory where you cloning to? | 11:24 |
|
| because that's really weird | 11:24 |
|
rhican
| running it as root, and it goes for a while about 80 lines or so of walk | 11:25 |
|
raalkml
| right | 11:25 |
|
rhican
| and gots and the files appear, but then it errors out and deletes all the files | 11:26 |
|
raalkml
| ok, than it is not the transport.. Can be a problem with the iwlwifi-repo | 11:26 |
|
| running git-fsck on it now | 11:27 |
|
rhican
| i upgraded to 1.5.0.3 i was using the 'stable' gentoo package 1.4.4 | 11:27 |
|
raalkml
| will see if it finishes (it's got only ~500 objects, why the heck does it take so long to fsck it...) | 11:28 |
|
| ok, it did finish. No errors aside from lots of dangling commits and tags... | 11:30 |
|
rhican
| 1.5.0.3 was successful | 11:30 |
|
| thanks for the help .. | 11:31 |
|
raalkml
| np. | 11:31 |
|
| ok, I don't know what it was :-/ | 11:32 |
|
rhican
| it was indeed pretty obscure google din't return any hits on it, git clone on other repositories worked though, so my client wasn't entirely borked | 11:33 |
|
| if you are curious http://rafb.net/p/Y5O16742.html was the end of the output of the 1.4.4 version | 11:35 |
|
| but it's fixed wii :D | 11:36 |
|
raalkml
| yes, probably it was.. | 11:54 |
| → alley_cat joined | 12:05 |
| → Romster joined | 12:09 |
| → nud joined | 12:23 |
| → bunk joined | 13:15 |
|
bunk
| anyone here to answer a git/cogito question? | 13:15 |
|
raalkml
| what question? | 13:16 |
|
bunk
| is there any command to show me between which two tags a commit is? | 13:16 |
|
raalkml
| gitk | 13:17 |
|
| in the lower pane, look at lines at the top of it | 13:17 |
|
| Follows/Precedes | 13:18 |
|
bunk
| raalkml: that's nice | 13:20 |
|
gitte
| bunk: git-describe tells you which is the preceding tag, too. | 13:20 |
|
bunk
| gitte: how can I translate v2.6.20-241-g725522b into something meaningful? | 13:23 |
|
gitte
| bunk: the first part is the tag, the next number (241) is how far back this tag is from the commit you are looking at. | 13:24 |
|
mugwump
| that means 241 commits after v2.6.20, commit id 725522b | 13:24 |
|
bunk
| gitte, mugwump: OK, thanks; for my purposes I can use this as "between v2.6.20 and the next tag" - and that's exactly what I wanted | 13:26 |
| → robfitz joined | 13:27 |
| → spearce joined | 13:35 |
|
gitte
| Hi spearce! | 13:35 |
|
spearce
| morning. this is very early for me. :-) | 13:36 |
|
| gitte looks outside and sees a bright spring afternoon sun. | 13:38 |
|
spearce
| heh. its a bright winter morning sun here. i just woke up about 5 minutes ago. still trying to clear the sleep grogginess from my head. | 13:38 |
|
| but our timezone was supposed to change today or something... and i don't think my computer TZ files are patched... so i'm not actually sure what time it is. | 13:39 |
|
| i *think* its 9:30, but i'm not sure that it is. | 13:39 |
|
gitte
| :-) Isn't it nice when some fools fool around with our time? | 13:41 |
|
| Just to show how powerful they are? | 13:41 |
|
spearce
| :) | 13:42 |
|
| my two gentoo boxes disagree now on the time. | 13:42 |
|
| one says 8:40, the other 9:40. wtf. | 13:42 |
|
gitte
| spearce: switch to UTC. Problem solved. | 13:44 |
|
spearce
| gitte: hah. then i'd be like 5 hours early to everything. | 13:44 |
|
gitte
| spearce: or 4? | 13:45 |
|
spearce
| yea. something like that. i hate time. :-) | 13:45 |
|
| i'm where i am when i get there. | 13:46 |
|
gitte
| spearce: speaking of time, do you know how those shift seconds are handled in Unix? | 13:47 |
|
spearce
| nope. | 13:47 |
|
gitte
| I always wondered... gmtime() is supposed to translate epoch (which is unambiguous) into the real time, which is ambiguous (you never know if two years from now, some hero like Dubya will wreck our lives again, this time by shifting new year by half a year) | 13:49 |
|
spearce
| yea. that part i got. but i don't know how gmtime does the crap that it does. :) | 13:51 |
|
| any last comments on GSoc2007Application ? | 13:54 |
|
| gitte is content with the content. | 13:55 |
| → yashi joined | 13:55 |
|
| spearce curses at his Congresscritters for stealing an hour from him today. | 13:59 |
| ← bunk left | 14:02 |
| → GeertB joined | 14:04 |
| → nud_ joined | 14:23 |
| → Romster joined | 14:24 |
|
spearce
| well, i'm finally done and happy with Soc2007Application. time to submit it i guess. | 14:34 |
|
jbowes
| i'm looking for something (easy) to hack on in git. anyone have any ideas? | 14:42 |
|
spearce
| jbowes: convert git-gc to a builtin? | 14:42 |
|
jbowes
| spearce: that would work. | 14:43 |
|
spearce
| lowest hanging fruit i can think of. ;-) | 14:43 |
|
jbowes
| spearce: thanks :) | 14:43 |
|
spearce
| jbowes: of course it also all depends on what sort of easy hacking task you are looking for. converting git-gc to a builtin requires c hacking (mainly 4 or 5 calls to run_command_*) and is by no means cool and exciting work. but it would be appreciated by folks on Windows, or who are working on more natively porting there. ;-) | 14:47 |
|
jbowes
| spearce: converting to builtins is exactly what i was looking for | 14:48 |
| → raalkml_ joined | 14:48 |
|
jbowes
| spearce: nice grunt work that requires little thought, but will help me get familiar with the code | 14:49 |
|
| spearce works on filling out Google's GSoC application thingy | 14:49 |
|
spearce
| jbowes: lots of that in builtin translation. ;-) | 14:50 |
|
| welp, GSoC app is submitted. lets hope they bite and select us! ;-) | 14:56 |
|
robinr
| spearce: got the eclipse repo imported in nine hours | 15:00 |
|
spearce
| robinr: is it that huge? i guess it is, huh, that project is huge. | 15:00 |
|
robinr
| the git packs take up 3 GB | 15:01 |
|
| I had to exclude the *-home directory (web sajts) which were 1.2 GB ,v files | 15:02 |
|
| it is probably better to split the repo somehow, but I don't know how yet | 15:02 |
|
| I used fromcvs, but I think you used something else with the mozilla experiments | 15:03 |
|
spearce
| yea - Jon Smirl hacked up cvs2svn to the same job that fromcvs does. | 15:03 |
|
robinr
| is it available somewhere? | 15:04 |
|
| and is it incremental? | 15:04 |
|
spearce
| no, Jon didn't release his code because it was a mess. and it wasn't incremental. | 15:04 |
|
robinr
| being a mess doesn't necessarily stop people from releasing code | 15:05 |
|
| sometimes people release the mess and let others clean up | 15:05 |
|
spearce
| true. but he sort of implicated it was such a mess he maybe didn't want his name associated with it. ;-) the other issue was the cvs2svn people rewrote huge chunks at the same time, making Jon's patches no longer possible to apply (or edit to apply either). that was about the time he got fed up with Mozilla not being interested in Git and the cvs2svn people not trying to fix their code to handle other weirdness in the Mozilla repository | 15:06 |
|
robinr
| he could release it anonymously :) | 15:06 |
|
| fromcvs at least looks good, well structured and well commented | 15:07 |
|
spearce
| i had the impression from corecode that it went faster than 9 hours... | 15:08 |
|
robinr
| depends on many factors | 15:09 |
|
| dual core CPU speeds up I believe | 15:09 |
|
spearce
| at least in the sense that fromcvs and fast-import can run in parallel to each other. :) | 15:10 |
|
robinr
| exactly | 15:10 |
|
| both consume a considerable amount of CPU, but most was in the ruby part | 15:10 |
|
| did corecode import the eclipse repo too? | 15:11 |
|
spearce
| no, i don't think he tried that one. | 15:11 |
|
robinr
| so how could he give any impressiona on speed on that one? | 15:11 |
|
| incremental import are much faster | 15:11 |
|
spearce
| he can't (and didn't). he did say he can import DragonFly BSD's repo in less than an hour (i think), and i was under the impression that was quite large as its the entire FreeBSD repo going back quite a ways. | 15:13 |
|
robinr
| I forgot to time the incremental import, but on the scale of 30 minutes | 15:14 |
|
| gitte wonders how Ruby can be slow, being interpreted and all :-) | 15:15 |
|
spearce
| either way, getting away from CVS is a good thing, and being able to do it in 9 hours and then incrementally afterwards is good. | 15:15 |
|
robinr
| I've no idea how fast that is. My guess is the total number of file revisions is the factor that determines the speed, more than KB's | 15:15 |
|
| most of the time of the incremental imports (for me is downloading a new archive and unpacking it). That's ~8 hours. | 15:16 |
|
| btw, I started caching commits for the eclipse history pane. That means I can se the history for resources being updated as I move around the project browser using arrow keys. | 15:17 |
|
spearce
| yea, i figured commit caching would be needed at some point. just never got around to do anything about that. | 15:18 |
| → kanru joined | 15:19 |
|
robinr
| I did try caching at other places but it turned out being slower | 15:20 |
|
| so commit caching at the Repository using a WeakHashMap seems to be the solution. | 15:20 |
|
| i'll probably send the patches today | 15:21 |
|
spearce
| yea - that's a pretty reasonable approach. | 15:21 |
|
robinr
| together with some bug fixes | 15:21 |
|
spearce
| both are always welcome. ;-) | 15:21 |
|
| i'm going to go spend some time with my better half, before she complains that i don't spend enough time with her. | 15:22 |
| → spuk joined | 15:28 |
| → GeertB joined | 15:40 |
| → devogon joined | 15:55 |
| → GeertB joined | 16:16 |
| → _jcrigby joined | 17:34 |
| → linuxmig1ation joined | 17:41 |
| → GeertB joined | 17:43 |
| → kukks joined | 17:45 |
| → raalkml joined | 17:46 |
| → GeertB joined | 17:54 |
|
corecode
| uhm | 18:12 |
|
| you were talking about fromcvs some time ago? | 18:12 |
|
| (reading backlog) | 18:12 |
|
| (well, hilights) | 18:13 |
|
robinr
| yes, i'll be back later... | 18:24 |
| → rphillips joined | 18:45 |
| → lyakh joined | 19:11 |
| → robin_ joined | 19:23 |
| → DrNick joined | 19:23 |
| linuxmig1ation → linuxmigration | 19:35 |
| → linuxmigration joined | 19:36 |
|
elmarco
| hey, I got some problem using cvsimport | 19:56 |
|
| git-cvsimport -v -d :pserver:anoncvs@anoncvs.freedesktop.org:/cvs/gstreamer -C gstreamer/common common | 19:57 |
|
| (if you want to try it, its very small) | 19:57 |
|
| fatal: Not a valid object name BRANCH-RELEASE-0_4_0 | 19:57 |
|
| git-cvsimport -v -d -p -b,HEAD ... seems to help | 20:08 |
|
robin_
| corecode: yes.... | 20:13 |
| → ferdy joined | 20:25 |
|
cehteh
| eh whats the semantic when merging files which got locally renamed? I rename foo.C to foo.cpp .. but upstream retains foo.C ... will a later merge from upstream merge his foo.C with my foo.cpp? | 20:33 |
| → wildfire` joined | 20:41 |
| → Eludias joined | 20:53 |
| → wildfire joined | 21:03 |
|
matled
| % git --version | 21:15 |
|
| git version gitgui.0.6.3.ge6d9-dirty | 21:15 |
| → mountie joined | 21:17 |
| → peff joined | 21:41 |
| → peff joined | 22:16 |
|
davi
| % git --version | 22:51 |
|
raalkml
| git version 1.5.0.3.495.gd041e | 22:51 |
| → orospakr joined | 22:54 |
| → orospakr_ joined | 23:09 |
| → orospakr__ joined | 23:17 |
| → orospakr__ joined | 23:21 |
|
chris__
| why can't I say git rm file && git commit file ? | 23:43 |
|
raalkml
| chris__: because it's not on index anymore (not git's file) | 23:44 |