Re: [darcs-users] so long and thanks for all the darcs

2018-04-08 Thread Evan Laforge
By the way, I found this thread really interesting and informative, and learned some things about git and version control. So thanks for the discussion. Content-addressed storage is pretty interesting. There was actually a filesystem based on this, for Plan 9, called fossil. It was a true

Re: [darcs-users] so long and thanks for all the darcs

2018-03-05 Thread Evan Laforge
On Mon, Mar 5, 2018 at 2:08 AM, Ben Franksen wrote: > I have just tried this and in fact when I resume the edit all the escape > sequences are printed literally. However, the editor does react to them: > I can quit using ":q" and the garbage on the screen isn't actually

Re: [darcs-users] so long and thanks for all the darcs

2018-03-05 Thread Evan Laforge
On Mon, Mar 5, 2018 at 1:19 AM, Ben Franksen wrote: > But you /can/ work in the same way with darcs: just don't (q)uit, rather > say (d)one. Then use 'darcs amend' to add more changes or 'darcs amend > --unrecord' to remove changes. There is also the --edit-long-comment >

Re: [darcs-users] so long and thanks for all the darcs

2018-03-04 Thread Evan Laforge
On Sun, Mar 4, 2018 at 2:46 AM, Ben Franksen wrote: >> There are a few other quibbles, like how obliterate -O is too slow to >> be useful, > > (perhaps we should have made --no-minimize the default?) Is that what you get when you ^C while it's working? If so, yeah I'd

Re: [darcs-users] so long and thanks for all the darcs

2018-03-03 Thread Evan Laforge
On Sat, Mar 3, 2018 at 6:26 PM, Karl O. Pinc wrote: > I use darcs, git, and mercurial; git only > for non-technical reasons. I'm pretty much on-board > with the git critique of: > https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/ Can't say I disagree much with that

[darcs-users] so long and thanks for all the darcs

2018-03-03 Thread Evan Laforge
I recently switched my main project from darcs to git. I'm mentioning it because I feel like it might be one of the larger and older darcs repos out there, with the exception of darcs itself (10 years, 6328 patches, around 140k lines of haskell). The reasons were that I wanted to use both diff

Re: [darcs-users] preparing a 2.14 release

2017-12-12 Thread Evan Laforge
ld be a good temporary solution until we > get it right. > > Guillaume > > 2017-12-12 16:06 GMT-03:00 Evan Laforge <qdun...@gmail.com>: >> Can we revert the patch that causes issue 2541? For me, the slowdown >> is a strong enough reason to either compile a 2.10

Re: [darcs-users] preparing a 2.14 release

2017-12-12 Thread Evan Laforge
Can we revert the patch that causes issue 2541? For me, the slowdown is a strong enough reason to either compile a 2.10 for linux (which I recall is tricky because you have to also install an old ghc) or migrate off darcs. I haven't done either yet because I mostly work on OS X and the 2.10

[darcs-users] OS X darcs 2.10.1 diff: darcs: /usr/bin/diff: fileAccess: permission denied (Operation not permitted)

2017-08-02 Thread Evan Laforge
I just wrote up this bug but then discovered it doesn't affect 2.12, so maybe it's not worth chasing down. Still though, 2.10.1 is the latest version with an OS X binary download, and compiling darcs yourself involves downloading a huge amount of haskell infrastructure, so I'd guess OS X people

Re: [darcs-users] whatsnew -l much slower in darcs 2.12.5

2017-07-31 Thread Evan Laforge
on with the cache system. I will try to > look at this soon. > > Guillaume > > 2017-06-25 2:00 GMT-03:00 Evan Laforge <qdun...@gmail.com>: >> I've been using the darcs 2.10.1 binary available for OS X, but I >> recently tried 2.12.5 and whatsnew -l is much slower.