Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2016-05-09

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:24 Riastradh joined #darcs
01:30 mizu_no_oto joined #darcs
02:48 mizu_no_oto joined #darcs
04:14 Big_G joined #darcs
08:09 Weltraumschaf joined #darcs
08:23 inhortte joined #darcs
09:35 Weltraumschaf joined #darcs
09:50 Weltraumschaf joined #darcs
11:19 mizu_no_oto joined #darcs
11:57 mizu_no_oto joined #darcs
12:47 mal`` joined #darcs
13:04 BitPuffin joined #darcs
13:50 gh_ joined #darcs
13:50 gh_ hi
13:51 gh_ fr33domlover, re: hashes, see http://darcs.net/Internals/Hashes
14:09 fr33domlover gh_, cool, thanks
14:28 pbgc joined #darcs
14:30 pbgc Hi. Sorry if it's a newbie question ...(and for my english) but I'm trying to install darcs 2.12 following the instructions: stack install darcs-2.12.0 .... and I get: "Error parsing targets: Specified target version 2.12.0 for package darcs does not match snapshot version 2.10.3" Can someone give me some help?
14:42 pbgc ok, sorry. Just found (https://www.stackage.org/lts-5.15/package/darcs-2.10.3) that I have to use --resolver nightly-2016-05-08 on the command line .. But it was not clear from the instructions http://blog.darcs.net/
14:53 Big_G joined #darcs
14:54 gh_ pbgc, sorry about that, I was lazy when I wrote the release notes and I am just waiting for stackage to catch up :x
14:54 gh_ I'm not (yet) a stack user
15:12 pbgc gh_: no prob! I was able to install it now .. and could learn a little more about stack :) thanks for the respose
15:44 amgarchIn9 joined #darcs
16:29 pbgc gh_: on the release notes it is said that darcs support was reintroduced in meld 3.15.2 .. but I could not use it until I changed the vc/__init__.py to include it ... (I filled a bug: https://bugzilla.gnome.org/show_bug.cgi?id=766185)
16:37 Weltraumschaf joined #darcs
18:11 prsai joined #darcs
18:12 pbgc joined #darcs
18:31 amgarchIn9 joined #darcs
18:31 fr33domlover joined #darcs
19:12 fr33domlover My hashed_inventory Attoparsec parser: http://hub.darcs.net/fr33domlover/vervis/browse/src/Darcs/Local/PatchInfo/Parser.hs
19:12 fr33domlover Tested on my darcs repos, so far works great
19:13 fr33domlover Also it uses the incremental parsing function so it can read a subset of the file etc. without loading the enire file to memory
19:14 fr33domlover (I'm using that for efficient pagination of darcs log web page etc.)
19:28 Heffalump fr33domlover: nice
19:34 prsai does darcs support pgp signed records?
19:34 Heffalump you can send patches signed, but there's nothing stored in the repo
19:35 prsai ok thanks
19:50 Weltraumschaf joined #darcs
19:55 fr33domlover prsai, technically I think you can gpg-sign a patch or a tag and use the signature as the patch's description :P
19:56 Heffalump fr33domlover: but the data you signed wouldn't be invariant under commutation
19:57 fr33domlover Heffalump, how does Git do it though? Git has Tag objects which among other things have a dedicated signature field, iirc
19:57 Heffalump fr33domlover: git doesn't commute things
19:58 fr33domlover Heffalump, what does commute mean in darcs? :P
19:58 Heffalump fr33domlover: changing a patches representation when you move it to another context, e.g. when cherry picking
19:59 Heffalump and merging does the same in reverse, and would also change the representation
20:00 sm git does something analogous during rebase, and its signed tags don't survive that either
20:01 sm (but unlike darcs, they do remain in the repo, pointing to the same as before)
20:01 Heffalump in darcs you can get back to the old one reliably, though you have to know "where" to go
20:09 sm Heffalump: oh really ? is the old version of a patch still in the repo after commutation ?
20:10 Heffalump sm: no (well, it's on disk until you do an optimize, I think) - but if you commute back to the original context you would have to get the same patch
20:10 Heffalump I imagine you would in practice in git too, but I don't think it guarantees it
20:10 sm hmm
20:13 dolio I wouldn't bet on it always being the case in git.
20:15 dolio Considering there are examples of the 3-way merge giving the wrong answer automatically, there are probably examples where rebasing twice gives you the wrong answer.
20:20 pbgc joined #darcs
20:32 prsai if I put a signed file of hashes of the files, refreshed for every patch, would work?
20:33 Heffalump what are you trying to secure against?
20:33 prsai malicious modification of the repo
20:36 Heffalump where - in transit, or on disk?
20:36 prsai both
20:39 Heffalump you can always sign any tree of files, indepdendent of a VCS
20:39 Heffalump so yes, that would work. But getting a signed history would be harder
20:40 prsai ok, it doesn't matter while the integrity of the code is guaranteed
20:41 Heffalump in theory, with a faked history, someone could influence the way a future merge worked
20:41 Heffalump but if you only care about the integrity of a specific repo state that's fine
20:43 prsai and for instance, an attacker could delete the last patch(es), that's possible
20:44 prsai and expose a user with an old version with security bugs
20:45 prsai but for that are the releases
23:00 prsai left #darcs

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary