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

[Evan Laforge]

On Sun, Mar 4, 2018 at 2:46 AM, Ben Franksen <ben.franksen at online.de> 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
optimize for speed over disk usage.

>> conflict markers don't label their sections, ^Z out of
>> editing a commit message can badly hose the terminal,
>
> I guess that is on Windows (it would be ^D or rather ^C on Linux and it
> works there). Our Windows support is lacking, sadly, mostly because I
> have not yet managed to set up an environment where I can build and test
> on Windows.

Actually it's xterm on linux.  I *think* I saw it on iterm2 on OS X as
well.  It doesn't happen with 2.10.1, and does with 2.12.5.

My guess it that it has to do with how darcs prompts put the terminal
into raw mode, then vim of course uses raw mode, somehow the state
saving and restoring gets messed up when you ^Z out and fg back in.
It's easy for me to reproduce:

Record changes in darcs 2.12.5, then say yes to "add a long comment"
where EDITOR=vim.  Now ^Z out of vim, and then fg back.  At that
point, vim is in command mode, but any keys just appear literally on
the screen, so there's no way to save or quit or do anything.  The
only way out is to kill vim from another terminal, at which point
darcs finishes the record (I guess it doesn't mind that vim return
nonzero?).

>> and you need an
>> obscure DARCS_DONT_ESCAPE_8BIT to show utf8 properly, but any complex
>> tool has its share of those kind of things.
>
> True. Just to mention it, I fixed this particular problem some time ago
> (not yet released, partly because it doesn't yet work on Windows as well
> as on Linux, see below).

Glad to hear :)

>> And then of course that it's
>> increasingly non-mainstream compared to git + github or gitlab, and
>> probably causes people to think twice before getting involved.  I
>> dislike a monoculture too but you can only die on so many hills at
>> once :)
>
> ;-) I have chosen to die on this one and don't expect many others to
> stay at my side... and I do need a somewhat longer break every now and then.

I'm glad someone is doing it, the commutative patch approach is quite
nice and it should be developed.

I also looked into pijul, but at the time the log command was broken
and it made me think if they're still at the state where basic
commands just don't work at all sometimes and no one notices then it's
not yet ready to trust with a real project.  I wish them luck too.

WRT branches, I too like the simplicity of them just being separate
repos.  Maybe this just needs a wrapper command that understands the
tree structure of the various branches, and then can do higher level
operations across branches like pull or push them all, or visualize
where they are, or whatever.  At least for me making the whole thing
feel lighter weight would go a long way, even if it's really the same
underneath.  The other thing would be making it all faster, maybe it
could be lazy by default or have some way to get a COW copy without
having to copy or hardlink a zillion patch files.  I guess the global
cache is already doing that, but it's still not sub-second, and it
seems to grow with repo size.

The idea of splitting the branch on a conflict is very interesting.
Sometimes it seems awkward to back out if I pull a conflicting patch,
so any pull can be scary.  I guess it's because the conflict detritus
gets mixed in with uncommitted local changes.  I would not be scared
if I knew that I could just delete the branch to back out.  Branching
history rather than mutating the present should be a familiar concept
to Haskell programmers :)

Also, I know this is external tool territory, but there really needs
to be some nicer way to merge than looking for 'v's and trying to
figure out what all those *s and =s mean and what happened and what
changed.  Even just documentation examples of how to integrate with a
3-way merge tool could help a lot.

While I'm at the wishing well it would be nice if interactive record
could save its state so you don't have to redo it all if you quit out
of it.  This could get the effect of git's staged commit but without
the complicated "cache" layer, just a file with the record state that
you can use to resume if you want.  I know I've whinged about this
before, but it *is* nice how in git I can do add -p, then quit, make
some more changes, add some more hunks, etc. and commit at the end.