2012-04-07 00:02 larsc: about the patches to the MIPS mailinglist: should I assume no news is good news, or does no news mean no action? 2012-04-07 00:02 I did Cc: those to Ralf 2012-04-07 00:03 I got reviews of two of the patches and fixed them to address the review comments, the third patch (multi-bank NAND) got no feedback 2012-04-07 00:04 the final patch is the one to make /dev/mem optional, I got the feedback that just making it optional is not enough, it should be made into a module 2012-04-07 00:04 which makes sense, I think, but is a lot more effort 2012-04-07 00:04 I plan to have a go at it though 2012-04-07 01:11 I'm having trouble with connecting the Nanonote to the network through usb. I get to the point on the wiki where it tells me to ssh or telnet into the Nanonote, but it always refuses the connection. 2012-04-07 01:13 hi xwalk 2012-04-07 01:13 dvdk: Hello. 2012-04-07 01:13 what does '/sbin/ifconfig usb0' output? 2012-04-07 01:14 and, btw, did yo uset a root password for the NN already? 2012-04-07 01:15 I did. 2012-04-07 01:15 http://pastebin.com/PZWTsadw 2012-04-07 01:16 There's the output of /sbin/ifconfig 2012-04-07 01:16 ok that looks fine. 2012-04-07 01:16 can you ping 192.168.254.101? 2012-04-07 01:16 and btw what's the output of 'route -n'? 2012-04-07 01:18 your dump even shows RX and TX bytes > 0 for usb0, so I guess you're almost there 2012-04-07 01:18 http://pastebin.com/U3Fm1033. There's the output of ''route -n" 2012-04-07 01:19 And yes, I can ping 192.168.254.101 2012-04-07 01:20 and doing 'ssh -v root@192.168.254.101' says what? 2012-04-07 01:20 btw route output looks fine, too 2012-04-07 01:21 It logs me into the Nanonote just fine. 2012-04-07 01:21 ?_? 2012-04-07 01:21 :) 2012-04-07 01:21 do you have network manager or some other troublemakers running? 2012-04-07 01:22 I'm using wicd on a hacked Debian Squeeze install. 2012-04-07 01:22 Hacked meaning it's a complete mess. 2012-04-07 01:23 well, next time connection fails, check ifconfig+route and see whether it changes for no apparent reason 2012-04-07 01:23 Right. Will do. Thanks so much for helping me. 2012-04-07 01:23 no prob 2012-04-07 01:24 btw when running the fw upgrade, you try to not use the 03-28 release which is still pretty "alpha" 2012-04-07 01:24 Gotcha. 2012-04-07 01:25 not broken per se, but lacks some software that refused compilation on latest new toolchain 2012-04-07 02:14 rejon_ has joined #qi-hardware 2012-04-07 02:30 hey, mplayer is working again !!1! 2012-04-07 02:31 wow :-) 2012-04-07 02:36 do we have a good software on the ben to play with discrete sampled values and signal processing? 2012-04-07 02:37 say applying windows, filters, conversions, etc... 2012-04-07 02:37 maybe gnuplot or octave? I need to try a little... 2012-04-07 02:40 dvdk has joined #qi-hardware 2012-04-07 02:46 ha, finally mplayer working with file selector dialog. 2012-04-07 02:49 [commit] David K 2012-04-07 02:59 excellent, thanks a lot! 2012-04-07 03:00 5 am in Berlin 2012-04-07 03:00 you are on a very unique schedule :-) 2012-04-07 03:02 adapting to family needs *and* coding needs some creative sleep patterns :) 2012-04-07 03:04 that said, time to get some more sleep hours. 2012-04-07 03:04 n8 2012-04-07 03:04 n8 2012-04-07 03:06 BTW you should try that, too: sleeping 3 hours, then waking 3 hours, then sleeping 3 hours at night. makes me a lot more productive 2012-04-07 03:06 :) 2012-04-07 03:07 hmm. maybe I try :-) 2012-04-07 03:35 rejon_ has joined #qi-hardware 2012-04-07 03:50 pabs3 has joined #qi-hardware 2012-04-07 04:12 infobot has joined #qi-hardware 2012-04-07 04:44 panda|x201 has joined #qi-hardware 2012-04-07 04:47 not THAT unique a pattern though ;-) 2012-04-07 05:11 whitequark: cool, do you plan to release it? 2012-04-07 05:49 The build has FAILED: http://fidelio.qi-hardware.com/~xiangfu/building/Nanonote/Ben/openwrt-xburst.minimal-20120406-0154 2012-04-07 06:44 jekhor_ has joined #qi-hardware 2012-04-07 06:53 capiscuas has joined #qi-hardware 2012-04-07 07:56 When installing xburst-tools for the Nanonote, am I installing that on the host machine or the Nanonote itself? 2012-04-07 07:59 Answered my own question, nevermind. 2012-04-07 08:36 hm 2012-04-07 08:36 I just found http://openinkpot.org/ 2012-04-07 08:37 grr how I hate trac. 2012-04-07 08:37 how can I donwload a trac site? 2012-04-07 09:06 jekhor has joined #qi-hardware 2012-04-07 09:23 rejon_ has joined #qi-hardware 2012-04-07 09:37 pabs3 has joined #qi-hardware 2012-04-07 09:40 http://git.openinkpot.org/ lots of repositories, most without telling for what. 2012-04-07 09:40 welcome to the dark side of git ;-) 2012-04-07 09:51 i know too many dark sides of git already :) 2012-04-07 09:52 git takes the worst of every user and makes it public :) 2012-04-07 09:53 Lying, history rewriting, forgetting branches, hiding work, ... 2012-04-07 09:54 And all while waving a flag "I'm a cool modern developer" 2012-04-07 09:54 t-shirt: "git reveals your inner Sauron" 2012-04-07 09:55 I've heard users saying: "Of course I edit my commits before pushing them. If I made public how I work, that would make look very bad publicly" 2012-04-07 09:55 well, it's about time we learn a few things from politics :) 2012-04-07 09:55 "make *me*" 2012-04-07 09:56 There are programmers heavily addicted to git, as it allows them to rework all they did, leaving no public trace of the edit 2012-04-07 09:56 it would also be rather confusing to follow :) 2012-04-07 09:56 And then they not accepting any other VCS that was made to keep the history of the development. 2012-04-07 09:57 i wouldn't call it an addiction, but of course, once you have the means to clean things up, you use it 2012-04-07 09:57 'clean things up', what an euphemism. :) 2012-04-07 09:57 We could do the same about Peron ;) 2012-04-07 09:57 well, with another vcs, you'd just not commit 2012-04-07 09:57 clean things up 2012-04-07 09:57 hehe 2012-04-07 09:57 hm scratch about Peron. Confusion :) 2012-04-07 09:58 (peron) the "peronist" government put pretty much a Ministry of Truth in place recently 2012-04-07 09:58 hehe 2012-04-07 09:58 That's what I mean 2012-04-07 09:58 Git gives everyone their own ministry of truth :) 2012-04-07 09:59 of course, that's not for covering up anything peron did. saints don't need that. if you questioned peron, what would be next ? maradona ? absurd 2012-04-07 10:00 I've seen git users really ashamed of the way they work 2012-04-07 10:01 well, the truth still comes out when you push. so it just allows you to split the usual workflow in a private and a public part 2012-04-07 10:01 LunaVorax has joined #qi-hardware 2012-04-07 10:01 they would probably be just ashamed with RCS ;-) 2012-04-07 10:01 no, the 'push' only contains your reworked version of "what happened" 2012-04-07 10:01 s/just/just as 2012-04-07 10:01 wpwrak meant: "they would probably be just as ashamed with RCS ;-)" 2012-04-07 10:02 So, I'm clearly in favour of using a VCS *to keep history* 2012-04-07 10:03 not only as a mechanism of *sharing code* (with no history saving), as git does. 2012-04-07 10:03 There are VCS who keep history, and also work well for sharing code. 2012-04-07 10:03 i don't see a big problem. git simply makes people commit things in smaller chunks - and then they realize the smaller chunks didn't make sense, they have an easy means to correct that 2012-04-07 10:04 if you can't do that, people simply don't commit before they think they're finished 2012-04-07 10:04 It's a manager of patches 2012-04-07 10:04 so with git, you may get ten small steps. with svn it would be a daily commit. 2012-04-07 10:05 svn is very cumbersome related to branches 2012-04-07 10:05 of course I don't mean people should not branch. svn makes people not branch, I think 2012-04-07 10:05 svn is very simple with branches. but not everyone likes that kind of simplicity ;-) 2012-04-07 10:06 yes, very simple 2012-04-07 10:06 you have changes to commit into a branch in your working dir... 2012-04-07 10:06 you only have to do "svn cp blablacurrentbranch blablanewbranch; svn switch blablanewbranch; svn commit" 2012-04-07 10:07 With attention at writting 'blablacurrentbranch', so it matches the version you are working *over* 2012-04-07 10:07 very simple :) 2012-04-07 10:07 cd ../other-branch; edit; svn commit ? :) 2012-04-07 10:07 wpwrak: you did not explain branch creation 2012-04-07 10:07 that's the approach svn experts recommended to me. or maybe it was an app-roach ? 2012-04-07 10:07 mkdir ;-) 2012-04-07 10:07 no 2012-04-07 10:08 mkdir does not branch :) 2012-04-07 10:08 it does. the directory hierarchy ;-) 2012-04-07 10:08 well, I mean branching from some files already comitted, not from a zero-files repository 2012-04-07 10:09 yeah. doens't svn cp do that then ? 2012-04-07 10:09 yes 2012-04-07 10:09 I wrote svn cp, you wrote mkdir :) 2012-04-07 10:09 ah, svn cp implies the mkdir ? didn't know that 2012-04-07 10:09 yes 2012-04-07 10:09 svn cp ^/trunk ^/branches/newbranch 2012-04-07 10:09 i actually never created an svn branch. used some, though 2012-04-07 10:09 svn switch ^/brancheS/newbranch 2012-04-07 10:10 i don't think i ever used svn switch, though 2012-04-07 10:10 But "^/trunk" may not be what are you working on.... 2012-04-07 10:10 So, it's a little cumbersome. 2012-04-07 10:10 Not to mention that there is almost no way of getting a branching/merging graph. 2012-04-07 10:11 which I find quite useful. 2012-04-07 10:11 As the graphs would go per-file, and not per-tree. 2012-04-07 10:11 so 2012-04-07 10:12 wpwrak: when I said some VCS do better at history keeping, I was not trying to recommend svn :) 2012-04-07 10:12 cvs then ? :) 2012-04-07 10:12 as my preference is not per-file graphs (like cvs or svn), but per-tree. 2012-04-07 10:12 There is monotone, fossil, even mercurial, who do quite a good job. 2012-04-07 10:13 I don't know bazaar. 2012-04-07 10:14 In any case... 2012-04-07 10:14 The drug of git spread. 2012-04-07 10:15 And every day more and more developers got comfortable in lying and rewriting their history of development before making it public. 2012-04-07 10:15 one thing i rather like about git are its fast local operations. not sure how well the others do in that regard. at least bzr seems to like to "call home" from time to time. not as bad as svn, but still 2012-04-07 10:15 Any DVCS will not call 'home' if you don't tell it to do so 2012-04-07 10:16 i really don't understand what you're complaining about 2012-04-07 10:16 :) 2012-04-07 10:16 ok 2012-04-07 10:16 I talk about git rebase, for example :) 2012-04-07 10:16 git rebase -i ? 2012-04-07 10:16 -i, and without -i 2012-04-07 10:17 You write a commit log for a tree, and then you rebase that commit, while not changing the commit log. 2012-04-07 10:17 well, without -i it has its uses for keeping branches up to date 2012-04-07 10:17 'merge' can also keep branches up to date. 2012-04-07 10:17 yes, but in a different way 2012-04-07 10:18 In a way that it keeps the history of what happened. 2012-04-07 10:18 By rebase, you move things happened before, as if they happened later 2012-04-07 10:18 what if you want a patch set you can submit ? then having merge points in the middle makes things messy 2012-04-07 10:18 And every commit log then talks about a *different tree* of what it was originally at time of writing. 2012-04-07 10:18 it's still consistent 2012-04-07 10:19 and it's up to you whether you need to update the commit log or not 2012-04-07 10:19 Because some people then describe in the commit log *the patch*, and not *the tree* 2012-04-07 10:19 And git becomes a patch manager 2012-04-07 10:19 well, i would expect the commit lot to indeed describe the commit ;-) 2012-04-07 10:19 While git manuals claim continuously that git makes a graph of "a file tree", and not "of patches" 2012-04-07 10:19 and yes, "patch manager" is precisely the role for which it would be used this way 2012-04-07 10:20 If you want a patch manager, you could use darcs, which is a VCS based on patches. 2012-04-07 10:20 file = patch ? :) 2012-04-07 10:20 But the git graph is not of patches 2012-04-07 10:20 it's a graph of file trees. 2012-04-07 10:20 details :) they're still commits 2012-04-07 10:21 haha 2012-04-07 10:21 and a commit is a patch, from a user's point of vew 2012-04-07 10:21 doesn't really matter how it's implemented under the hood 2012-04-07 10:21 then where would you claim anything about the state of a file tree, if not the commit log? 2012-04-07 10:22 as in "I tested this, and works" 2012-04-07 10:22 perhaps in a mail asking upstream to pull / merge / whatever ? :) 2012-04-07 10:22 hahaha 2012-04-07 10:23 obviously, if you make this kind of claims in the commit log, there's a risk of inconsistencies 2012-04-07 10:23 then better not to do claims about the tree 2012-04-07 10:23 you have to decide whether the information is worth the trouble or not 2012-04-07 10:23 And once you rebase... 2012-04-07 10:23 How do you get back in case of wanting to know what happened? 2012-04-07 10:23 The reflog does not get public 2012-04-07 10:24 well, human being are pretty decent at dealing with moderately inconsistent information 2012-04-07 10:24 how do you know the statement was ever true ? 2012-04-07 10:25 wpwrak: I don't know if it was true. But at least context of the statement would be reproducible :) 2012-04-07 10:25 maybe the committer already lied the first time. maybe he wrote " i tested it" because his boss told him to test it. but in reality, he didn't feel like working late, so he didn't test. 2012-04-07 10:25 if you go that way, we could stop using VCS at all ;) 2012-04-07 10:26 kristoffer has joined #qi-hardware 2012-04-07 10:26 he was in a hurry to get out of the office because he was going to a party. there, he got very drunk. forgot all about the last few hours. there was nobody else in the office. no chance of reproducing the context. 2012-04-07 10:26 ;) 2012-04-07 10:27 You can also write a novel in commit logs, instead of explaining what you did there :) 2012-04-07 10:27 some people seem to apply that context. particularly surrealists 2012-04-07 10:27 But I mean that git invites you, in quite enough operations, to unlink the context of the "commit log" assertions. 2012-04-07 10:27 With no possiblity of going back. 2012-04-07 10:27 s/context/concept 2012-04-07 10:27 wpwrak meant: "some people seem to apply that concept. particularly surrealists" 2012-04-07 10:28 can't you rebase back ? 2012-04-07 10:28 back to what? 2012-04-07 10:28 back to the previous base 2012-04-07 10:28 how do you know the previous base? 2012-04-07 10:29 What if there were conflicts? 2012-04-07 10:29 its lost. loooost 2012-04-07 10:29 :) 2012-04-07 10:29 git rebase --abort ;) 2012-04-07 10:29 Git is the only VCS where I lost code. :) 2012-04-07 10:29 disappeared. shazam. :) 2012-04-07 10:30 chances are it was still there ... just hard to find 2012-04-07 10:30 haha 2012-04-07 10:30 git rarely loses things. but it's good at hiding them 2012-04-07 10:30 you have one month of reflog 2012-04-07 10:30 and garbage collection from time to time. 2012-04-07 10:30 (By default) 2012-04-07 10:30 yup :) 2012-04-07 10:30 perfect :) 2012-04-07 10:31 Quoting a friend, /dev/null perfoms better ;) 2012-04-07 10:31 performs 2012-04-07 10:32 And I think next git versions may finally remember the branch names 2012-04-07 10:32 in what way ? 2012-04-07 10:32 in history 2012-04-07 10:32 I don't know how. 2012-04-07 10:32 I heard the claim 2012-04-07 10:32 Now branch names disappear if you remove them (due to a branch being merged9 2012-04-07 10:32 ) 2012-04-07 10:33 and history only shows a graph of unnamed branches 2012-04-07 10:33 the merge commit will still tell you what you merged 2012-04-07 10:34 and if it's a fast-forward, then you may simply have had a topic branch 2012-04-07 10:34 and all gets serialiezd. 2012-04-07 10:34 not sure if you can force a merge commit, though 2012-04-07 10:34 serialized 2012-04-07 10:34 that's often the idea 2012-04-07 10:34 I know 2012-04-07 10:34 I dislike all that :) 2012-04-07 10:35 i just gives you more flexibility 2012-04-07 10:35 You get a serialized graph of commits with dates not matching anything at all the serialisation 2012-04-07 10:35 more flexibility at the expense of loosing history information of what happened. 2012-04-07 10:36 phew. and if people don't NTP-discipline their clocks, i guess you go around and murder them in their sleep :) 2012-04-07 10:36 ;) 2012-04-07 10:37 dvdk: for the mplayer menu are you using its OSD menu feature? 2012-04-07 10:37 wpwrak: you are addicted ;) 2012-04-07 10:38 if your VCS prevents you from having topic branches, but you want to work undisturbed on some changes, you'll then simply not switch branches or incorporate changes. and you may even cp your files away, update, then cp them back. where's your history then ? 2012-04-07 10:38 git addicted consider it very normal to hide or edit development procedures before sharing a private development graph. 2012-04-07 10:39 it's nothing i hadn't done with CVS and SVN before 2012-04-07 10:39 wpwrak: what's different between branches and topic branches? 2012-04-07 10:40 git simply does not have operations to do what you want other than by loosing the history of what you do 2012-04-07 10:40 losing 2012-04-07 10:40 nothing really. "topic branch" just narrows the purpose. i.e., it's work on the main branch, but you branch off it to avoid clashing with changes on the main branch (until you're ready for merging) 2012-04-07 10:40 many VCS support branches :) 2012-04-07 10:41 "topic branch" is a user-level concept 2012-04-07 10:41 VCS let you use branches for whatever you want 2012-04-07 10:41 but some require more typing (like svn), but keep history (per-file, not per-tree) 2012-04-07 10:41 (losing history) perhaps you should also ask developers to install a webcam so that you can record how they work 2012-04-07 10:41 wpwrak: haha :) ok 2012-04-07 10:42 pabs3: yes, it's MIT and already on github 2012-04-07 10:42 i don't understand why you insist on preserving history that the developers don't want preserved 2012-04-07 10:42 pabs3: http://github.com/whitequark/furnace-avm2.git 2012-04-07 10:42 Publishing the history of the files you work on is an attack against privacy. 2012-04-07 10:42 see :) 2012-04-07 10:43 also, when i try to follow development, i prefer a clear line 2012-04-07 10:43 git not only allows you to keep some things private. The git code sharing models I've seen invite you to keep your development private. 2012-04-07 10:43 i don't really want to know all the small mishaps that occurred along the way and how they were reverted 2012-04-07 10:44 i want to know the final solution that was finally found worth keeping 2012-04-07 10:44 that's the matter of a viewr. 2012-04-07 10:44 viewer 2012-04-07 10:44 viric: what do you think is the goal of DVCS, making code access more convenient or preserving some random sequence of actions no one cares about? 2012-04-07 10:44 it's a matter of not wasting my time :) 2012-04-07 10:44 random sequence of actions? 2012-04-07 10:44 Who talked about random sequences of actions? 2012-04-07 10:44 yes, exactly 2012-04-07 10:44 whitequark: cool, thanks 2012-04-07 10:44 (git code sharing) yeah, the pull model has that effect. but it's just one possible model. 2012-04-07 10:45 pabs3: just curious, what do you want to use it for? 2012-04-07 10:45 wpwrak: I've some complaints against git, lacking some features. But most of my complains go to that way of using git :) 2012-04-07 10:45 Aylax has joined #qi-hardware 2012-04-07 10:45 whitequark: you consider your development 'random sequence of actions'? 2012-04-07 10:46 whitequark: nothing right now. maybe in the future it might be useful for adding support for some website to get-flash-videos 2012-04-07 10:46 viric: in essence, yes. "git rebase" allows you to take your commits and rework them in a way which actually makes sense from a logical perspective. 2012-04-07 10:47 e.g. "one encapsulated change" = "one commit" 2012-04-07 10:47 viric: i find that my development often consists of actions based on a lack of comprehension 2012-04-07 10:47 that greatly helps with reviewing, bisecting, searching bugs, viewing logs and whatnot 2012-04-07 10:47 viric: there's very little value for others to follow my through process at that level 2012-04-07 10:47 s/through/thought 2012-04-07 10:47 wpwrak meant: "viric: there's very little value for others to follow my thought process at that level" 2012-04-07 10:47 ^ that. 2012-04-07 10:48 whitequark: exactly :) 2012-04-07 10:48 well, it's clear where we disagree. I think it is of great value to have the history of what happened. 2012-04-07 10:48 There is no reason to destroy that. 2012-04-07 10:49 viric: I gave you a reason 2012-04-07 10:49 viric the historian ;-) 2012-04-07 10:49 whitequark: presenting a development and the history of the development could be both stored. 2012-04-07 10:49 whitequark: whats this abcdump.abc file? 2012-04-07 10:50 pabs3: an ABC bytecode dumper, compiled from Tamarin sources 2012-04-07 10:50 http://hg.mozilla.org/tamarin-central/file/fbecf6c8a86f/utils/abcdump.as#l1077 2012-04-07 10:51 You could present what you want others to care of your development in the log of a merge, without destroying the history of what you did. But git addict peoples *first* think on destroying what they did, and then think out how to present it anew. 2012-04-07 10:51 now you're making personal attacks 2012-04-07 10:51 haha 2012-04-07 10:52 (not that I care) 2012-04-07 10:52 well, I already said that I'm against how many users use git. 2012-04-07 10:52 not against the software. :) 2012-04-07 10:52 and on merges... when bisecting or reading log, you don't pick a giant merge and then dig into how it works 2012-04-07 10:52 Against, in a sense that I dislike that approach to sharing code. 2012-04-07 10:52 you just read the descriptions for the commits which do actual work 2012-04-07 10:53 I understand, yes. 2012-04-07 10:53 You take the graph of commits as if it was a way to show a development, and that can be unrelated to how you did the development. 2012-04-07 10:53 can you suggest a reason for preserving exact development path? 2012-04-07 10:53 also 2012-04-07 10:53 what should I do if I accidentally committed 110MB of .o files in? 2012-04-07 10:54 :) 2012-04-07 10:54 or a bunch of non-free patent-covered code 2012-04-07 10:54 or whatever 2012-04-07 10:54 The VCS software should let you do all you want. 2012-04-07 10:54 fix those cases, too. 2012-04-07 10:54 But I don't think it should *invite* to destroying how you did the development. 2012-04-07 10:55 viric: what value the data about "how did you do the development" has? 2012-04-07 10:55 The effect of that is that some developers get addicted to that model, and then they get ashamed of showing their development publicly 2012-04-07 10:55 zero 2012-04-07 10:55 would you also suggest to store the data about disk drive head moves in the DVCS? 2012-04-07 10:55 just because you can 2012-04-07 10:55 or perhaps even negative, because you may rely on that "information" 2012-04-07 10:55 and hey, it's DATA! let's preserve it 2012-04-07 10:55 Yes, I consider the history has some value 2012-04-07 10:56 what value? 2012-04-07 10:56 for what could it be used? 2012-04-07 10:56 in understanding what you did one thing or the other. But well, you can also go on writing misleading commit logs too, and then have no value in that 2012-04-07 10:56 in real world, that is. for what business task would you use it? 2012-04-07 10:56 If you do 'random commits', there is no value. 2012-04-07 10:56 :) 2012-04-07 10:56 people generally do mistakes most of the time 2012-04-07 10:56 if there was something important you learned in the process, then you should document it. a VCS that preserves every keystroke would invite you to not do this, because the "information is already here" 2012-04-07 10:56 hence, commits are generally random 2012-04-07 10:56 ok 2012-04-07 10:57 hint: visualizing the history of project developing, or, I dunno, tracking the count of code lines written by each developer, or something like that is not a business task 2012-04-07 10:57 it doesn't add any value to your work 2012-04-07 10:58 for a FOSS project a "business task" could be considered as some task which could help it gain more users 2012-04-07 10:58 or compete better with non-free replacements 2012-04-07 10:58 clear, I understood about the value of random commits, and I agree. 2012-04-07 10:59 what we're writing software (including FOSS) for? sharing the source? actually no, that's just a way to do it more effectively. we write software to do real work. 2012-04-07 10:59 (if someone thinks that he should write a piece of software exactly for sharing the source, you're unfortunate enough to get gcc.) 2012-04-07 11:00 Maybe it is that I consider my commits (and those of who I work with) not that random 2012-04-07 11:00 viric: ok, let's only look at "non-random" commits 2012-04-07 11:00 what the history of these commits could be used for? 2012-04-07 11:00 1) I think it helps understanding the situation in case of troubles 2012-04-07 11:01 a typical case would be that you do thing X. then you realize that X doens't solve the problem properly, and you do Y instead. now, if you think it's likely that someone else would also think X is a good or maybe even better solution, you should write a comment right there. 2012-04-07 11:01 2) It can allow others to understand ways of finding solutions to problems 2012-04-07 11:01 3) And it can help others not feel shame for their way of working 2012-04-07 11:02 I'm hitting more and more cases of paranoid people who don't accept anything other than git due to '3' 2012-04-07 11:02 so, basically, you state that a VCS must store the code in such a way that novice developers could learn from it, and force everyone else to do their work in a way which would help these novice developers? 2012-04-07 11:02 perhaps you;re misinterpreting their motives 2012-04-07 11:03 because 1. is solved by debugging, not digging into VCS logs. if you have a piece of code which doesn't work, you insert some checks in it and see where did it go wrong. 2012-04-07 11:03 whitequark: it sounds more as if he's asking for the VCS to keep tons of useless information around, making it harder to find the relevant information 2012-04-07 11:03 wpwrak: I'm trying to understand the motive 2012-04-07 11:03 viric: do you read all your mails ? including the spam ? :) 2012-04-07 11:03 I would almost not call git a VCS, but a code-share system 2012-04-07 11:04 * whitequark facepalms 2012-04-07 11:04 whitequark: maybe we just have to wait until the drugs wear off :) 2012-04-07 11:04 Well, I think I'll leave the talk in disagreement :) we have all different motivations 2012-04-07 11:04 wpwrak: ROFL. 2012-04-07 11:05 I'll just go destroy some history 2012-04-07 11:05 hehe 2012-04-07 11:05 yes, noone should care on the random commits :) 2012-04-07 11:05 I can't even imagine what would happen to Linux if the commits in it would be like you're suggesting 2012-04-07 11:06 because when I ported it to a some MIPS device, I did a ton of different commits over several weeks, and shared that with others who tried to hack on it too 2012-04-07 11:06 only maybe 10% of that code was useful enough to get into the final version 2012-04-07 11:07 and I have spent a lot of time rewriting it into a form where each commit was self-contained and you could actually read it and get what would happen when you apply it 2012-04-07 11:07 because otherwise it was a huge heap of intermingled parts of different experiments 2012-04-07 11:07 and I'm quite sure it's not just me who cannot develop good enough software^Wcommits 2012-04-07 11:08 who goes to the linux git and wants to see "how is linux developed"? 2012-04-07 11:08 erm. what? 2012-04-07 11:08 I mean 2012-04-07 11:08 I think of use cases where people want to know about the development of a very particular piece 2012-04-07 11:08 when my device hangs instead of going to sleep after some commit, I go and bisect it 2012-04-07 11:08 then I find the piece of code which caused this 2012-04-07 11:09 I want it to be a carefully written 5 lines of code with 10 lines of description which tells me everything about how it works 2012-04-07 11:09 We have too separate visions to make them common in a short time :) 2012-04-07 11:09 I leave the talk for another day :) 2012-04-07 11:09 not a 100+ line diff with all the shit which was in the head of developer and some babbling instead of comments 2012-04-07 11:09 ok 2012-04-07 11:11 whitequark: in fact, with viric's approach, you'd most likely hit a branch you later rejected 2012-04-07 11:12 whitequark: bisecting assumes a perfect world of linear development. reality is different, but still close enough that bisecting is often useful. if you kept all the junk around, too, then that would rarely be the case. 2012-04-07 11:13 whitequark: of course, you could keep the junk around AND tell your vcs what the things are that you finally kept, but i doubt a lot of people would make the effort of keeping this sort of information in good shape 2012-04-07 11:15 most of people just commit all the junk to git and don't care 2012-04-07 11:15 and this is SO annoying 2012-04-07 11:16 in 80% FOSS projects, notably those with 1-2 developers, commit logs are of no value at all 2012-04-07 11:16 precisely because of the no-rebase approach 2012-04-07 11:16 if you're a good upstream for them, you then simply send them back for cleanup :) 2012-04-07 11:16 that works for kernels, or maybe for gcc 2012-04-07 11:17 in the world of web-development it doesn't. people either really don't understand/know how to use good programming practices, or don't have enough time to do the right thing 2012-04-07 11:18 well, web-development ... most of that is bottom-feeding anyway ;-) 2012-04-07 11:18 bottom-feeding? 2012-04-07 11:18 you mean the model of consuming content in web? 2012-04-07 11:18 a lot of the work that goes into presenting that content 2012-04-07 11:18 I don't care about the web itself in this context. I'm talking solely about the development of software to drive the web. 2012-04-07 11:19 web is moving fast 2012-04-07 11:19 both are horrible 2012-04-07 11:19 way faster than you can keep with and write good software 2012-04-07 11:19 that's why we have PHP, for example 2012-04-07 11:20 or consider Rails, my framework of choice. it's somewhat good; for example, at one point the core team decided to take a break and spent a year on major refactoring 2012-04-07 11:20 many things have no need to move fast all the time. eventually, your core functionality will settle. or you're screwed anyway :) 2012-04-07 11:20 it was a very good decision. 2012-04-07 11:20 Rails itself and a bunch of libraries (less than half a dozen) which are used very often are written really good 2012-04-07 11:21 80% of other software associated with it (plugins, tools, etc.) definitely isn't 2012-04-07 11:21 and this is a good statistics if we take the overall web-related software 2012-04-07 11:22 in this case it happened this way because, I think, some Ruby features make you stop for a minute, think about what you're doing and then write some good code, because otherwise it just won't work good 2012-04-07 11:23 nah. just take a look at node.js. 2012-04-07 11:23 all of the former jquery monkeys use it. you can see the result. 2012-04-07 11:24 when you're a "jquery programmer" (hint: it's like "boost programmer" for C++), it isn't any good 2012-04-07 11:27 [commit] kyak: mplayer: get rid of X11 runtime dependency (master) http://qi-hw.com/p/openwrt-packages/f76d692 2012-04-07 11:30 xwalk has joined #qi-hardware 2012-04-07 11:32 also the linux desktop evolves fast 2012-04-07 11:33