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

[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 put
> in the log. Still a bug which I intend to fix, see
> http://bugs.darcs.net/issue2572.

Good deal.  I know these kinds of weird terminal interaction bugs are
not necessarily easy or fun to track down, but it's one of those
usability details that no one notices when it works and everyone
complains when it doesn't :)
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

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

[Ben Franksen]

Am 05.03.2018 um 10:19 schrieb Ben Franksen:
> Am 05.03.2018 um 03:40 schrieb Evan Laforge:
>> 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?).

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 put
in the log. Still a bug which I intend to fix, see
http://bugs.darcs.net/issue2572.

Cheers
Ben

___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

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

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

Yes, I also often worked this way.  I don't know why I didn't use it
more than I did though... maybe because of:

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

Yes, I have definitely wanted exactly this feature more than once.
I'm all for it.
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

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

[Ben Franksen]

Am 05.03.2018 um 01:47 schrieb Karl O. Pinc:
> On Sun, 4 Mar 2018 23:23:33 +0100
> Ben Franksen  wrote:
> 
>> What made me re-consider
>> the idea was that I found I like the way mercurial automatically
>> creates a branch when you pull a conflicting patch.
> 
>> But
>> when you look at it from a darcs viewpoint, automatically creating a
>> branch really makes sense only if there is no "clean" merge, that is
>> if there is a conflict; otherwise you just pull patches and that's it.
> 
> FYI.  I regularly pull with --no-allow-conflicts.

Me too. I have this set in my ~/.darcs/defaults ever since rebase came out.

>> In contrast, branches are fully symmetric: none is better
>> than the other, patch identities remain unmodified, and you can
>> switch between them easily.
> 
> Would be nice to be able to assume that the remote repo 
> is not "better".

Yes.

>> These are all pretty raw ideas at the moment, none of it is
>> implemented. There are lots of open questions regarding UI design etc.
> 
> I know a lot of thought gets done on IRC 

I am mostly using the lists and the bug/patch tracker. However, most of
it is on the darcs-devel list, partly because all changes and comments
in the tracker are auto-forwarded as emails to the devel list.

> but as far as UI
> goes it might be good to run thoughts by this mailing list.

Yes, UI and design of new features should be discussed here in public
where some of our users hang out. Will try to remember. If it starts out
via tracker, we should add darcs-users to the nosy list. This may spam
you with technical details every now and then but I guess that's acceptable.

Cheers
Ben

___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [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  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
>