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

[Ben Franksen]

Am 05.03.2018 um 03:40 schrieb 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.

Perfectly reasonable, that's what ~/.darcs/defaults is for.

However, disk usage wasn't the motivation for minimizing the context.
Instead, the main motivation was to increase the chance that the bundle
can be applied even if some of its original context is missing. If your
patch history is [A,B,C] and C is obliterated with -O --no-minimize,
then the context is [A, B] and the bundle cannot be applied to [A], even
if C does not depend on B. You could work around that by manually
editing the context in the bundle (it's a plain text file) which I did
several times in the past before I opened a ticket for this feature and
someone else implemented it.

>>> 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.

Okay, I misunderstood. You suspend the editor with ^Z.

> 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?).

Thanks for clarifying. I will open a ticket and perhaps try to fix that one.

> 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.

Me too, i think the idea is great, but - as always - the devil is in the
details.

> 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.  

See my reply to Karl on this thread. Let me add that adding in-repo
branches would not be a big change in the underlying structure. Quite
the opposite, as I recently realized we have everything we need already
in place.

Patches are organized in what we call "inventories". These are files
that record which patches are applied in which order. Inventories are
stacked: when you tag a repo the current inventory is closed and a new
one is opened, starting with a reference to the old one.

So an in-repo branch is simply another top-level inventory. All we need
to add is a new directory _darcs/branches to store the currently
inactive branches (=inventories). (Now, as I write this down, i also
realize that we probably want to store pristine trees for each branch,
so that switching between repos will be fast.)

> 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.

Yes to all you said here.

I guess we should really bundle all patches beyond the most recent tag
into one big file by default. It is pretty uncommon to work with patches
behind a tag.

> 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 :)

Yes!

> 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.

I think there are options to invoke a third-party merge tool during
pull, but I haven't used them so I can't comment on how well that works.

Regarding the conflict markup: we all agree that this is a very weak
point in darcs as it stands. Unfortunately, the code that creates the
data for conflict markup is one of the most difficult to understand
parts of darcs. No doubt David Roundy is a genius but writing code so
that other people can comprehend what's going on wasn't high on his list
of priorities. So making changes to this part is hard. Furthermore, this
code differs fundamentally between darcs-1 and darcs-2 formats (because
of fundamental differences in how conflicts are represented), so I guess
any improvements will be limited to the darcs-2 format.

> 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.

I fully agree. Die-hard mercurial fans frown upon it because of its
double use as 'file add' operation (which git doesn't have), but IMO
staged commit is a very nice feature in git, considering its
non-interactive-by-default nature.

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
option for amend.

We could improve the workflow a bit by presenting the changes in the
opposite order with 'amend --unrecord', so it acts more like an undo.

Cheers
Ben