Re: [darcs-users] RFC: Hiijacking Patches

2020-09-25 Thread Ben Franksen
Am 25.09.20 um 16:42 schrieb James Cook: > Is hijacking patches a common operation for anyone? The least > surprising behaviour would be to always ask the user what to do if > they haven't explicitly chosen an option on the command line; I'd > certainly prefer that. But I've never needed to hijack

[darcs-users] RFC: safer default for patch editing operations

2020-09-25 Thread Ben Franksen
Hi Everyone Since 2.16 the --not-in-remote option is supported for all operations that edit the history: amend, rebase suspend, obliterate, and unrecord. Should we make this the default behavior? My rationale is that this is usually what you want. Unless modified with --set-default, the

[darcs-users] RFC: Hiijacking Patches

2020-09-25 Thread Ben Franksen
Hi Everyone I am thinking about changing the behavior and/or available options for hijacking patches. Context: When working from home I have two identities in my ~/.darcs/author file: one with my work email address and one with my private email address. I want to decide which one to use per

Re: [darcs-users] How to extend a patch theory to fully commute

2020-09-17 Thread Ben Franksen
>> Conflictors in Darcs can be seen as "internalizing" the relevant parts >> of the above tree structure /into/ the (conflicted) patch >> representation. This is the source of their complexity. What we gain >> form that is the possibility arrange all patches in a repo in a linear >> sequence where

Re: [darcs-users] How to extend a patch theory to fully commute

2020-09-17 Thread Ben Franksen
Am 17.09.20 um 01:51 schrieb James Cook: >> So this can succeed only if c does not conflict with either of its >> sibling cancelled branches, that is, if c^ commutes with all sequences >> ("paths") in the cancelled branches, that is, all elements of {d, e;f, >> e;g, e;h;i}. We then get >> >>

Re: [darcs-users] How to extend a patch theory to fully commute

2020-09-11 Thread Ben Franksen
Hi James I think I mentioned that inverses in patch theory always confuse me. So I may be talking nonsense here. My current thinking is this: When we add names to primitive patches, we implicitly make the theory asymmetric in the sense that /new/ patches can enter the scene only as positive

Re: [darcs-users] How to extend a patch theory to fully commute

2020-09-08 Thread Ben Franksen
Am 08.09.20 um 21:47 schrieb James Cook: In your case, for two adjacent /sequences/ A;B, and equivalences A~A', B~B', we need to have that A;B commutes iff A';B' commutes. Now, suppose you have patches a;b;b^;c, where none of the adjacent pairs commute. You'd have to show that

Re: [darcs-users] How to extend a patch theory to fully commute

2020-09-08 Thread Ben Franksen
Am 08.09.20 um 17:29 schrieb James Cook: > On Thu, 3 Sep 2020 at 14:24, Ben Franksen wrote: >> >>>>> If I wanted to implement it, I think it would just become this: >>>>> >>>>> * A repository consists of two things: >>>>>

Re: [darcs-users] How to extend a patch theory to fully commute

2020-09-03 Thread Ben Franksen
>>> If I wanted to implement it, I think it would just become this: >>> >>> * A repository consists of two things: >>> * A sequence S of primitive patches with distinct names, starting at >>> O, with no inverses (i.e. only positive names). >>> * A set of names, called "tombstones",

[darcs-users] [ANN] Darcs 2.16.2 release

2020-08-21 Thread Ben Franksen
On behalf of the Darcs team, I would like to announce the release of Darcs 2.16.2. It turned out that darcs-2.16.1 cannot be built by downloading the source tar ball, unpacking it, and then running 'cabal install' inside the source folder. We have released Darcs 2.16.2 to fix this. There are no

Re: [darcs-users] How to extend a patch theory to fully commute

2020-08-19 Thread Ben Franksen
Am 19.08.20 um 11:44 schrieb Ben Franksen: > The fact that your patches have no "content" is of of course a result of > starting out with "enriched" contexts. As you note in 2.2 > Interpretation, your contexts can *not* in general be understood simply > as "w

Re: [darcs-users] How to extend a patch theory to fully commute

2020-08-19 Thread Ben Franksen
Am 19.08.20 um 03:26 schrieb James Cook: >> I changed the definition of Context >> Address to work better with my new "patch universe" definition, but I >> think it amounts to the same thing. > > Thinking about it more, I'm not sure my new definition of Context > Address is a good one, since I've

Re: [darcs-users] How to extend a patch theory to fully commute

2020-08-19 Thread Ben Franksen
Am 18.08.20 um 22:42 schrieb James Cook: > Okay, I wrote something up: https://www.falsifian.org/a/xxOw/misc.pdf I like it. Especially the part where you define commutation in terms of the balance-respecting property. This is very elegant. It confirms what I have long since suspected, namely that

[darcs-users] [ANN] Darcs 2.16.1 release

2020-08-14 Thread Ben Franksen
Hi Everyone On behalf of the Darcs team, I would like to announce the release of Darcs 2.16.1. This new release [1] contains a rather large number of bug fixes and many other goodies. If you are interested in the details, please look at the CHANGELOG [2]. The most up-to-date documentation is

Re: [darcs-users] How to extend a patch theory to fully commute

2020-08-13 Thread Ben Franksen
Am 13.08.20 um 19:54 schrieb James Cook: > Question: is there a good place to read about how "darcs pull" works? I am not aware of anything that you could read. What happens is basically this: We read the _darcs/hashed_inventory of both the local and remote repo. These give us the latest know

Re: [darcs-users] How to extend a patch theory to fully commute

2020-08-08 Thread Ben Franksen
Am 08.08.20 um 22:51 schrieb James Cook: >> Why are you so hung up on this tree / cycle thing? What is wrong about >> your original context addresses and patch (sequence) adresses? If >> efficiency is the concern, we are talking about a factor of two here. >> This is irrelevant. For the theory you

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-07 Thread Ben Franksen
Definition: A category X is said to be an inverse category whenever, for each arrow f : A -> B in X, there exists a unique f^ : B -> A in X such that ff^f = f and f^ff^ = f^. (I write composition as juxtaposition without an operator.) Given a universe of extended invertible patches, define a

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-06 Thread Ben Franksen
Am 06.07.20 um 19:37 schrieb James Cook: > On Mon, 6 Jul 2020 at 10:29, Ben Franksen wrote: >> Am 05.07.20 um 20:36 schrieb Ben Franksen: >>> Am 04.07.20 um 23:59 schrieb James Cook: >>>>> I think that whenever a sequence of patches starts and ends at a >>&

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-06 Thread Ben Franksen
Am 06.07.20 um 19:33 schrieb James Cook: >> I guess you want to avoid proper cycles, i.e. cycles other than those of >> the form patches;patches^, but that's just an intuition. > > A;A^;B;B^;C;C^ isn't a proper cycle in that sense but may be useful to > be able to have if you're merging or have

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-06 Thread Ben Franksen
Am 05.07.20 um 20:36 schrieb Ben Franksen: > Am 04.07.20 um 23:59 schrieb James Cook: >>> I think that whenever a sequence of patches starts and ends at a >>> primitive context (e.g. this is true of an unconflicted repository) >>> you can re-order the patches

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-05 Thread Ben Franksen
Am 04.07.20 um 23:59 schrieb James Cook: >> I think that whenever a sequence of patches starts and ends at a >> primitive context (e.g. this is true of an unconflicted repository) >> you can re-order the patches so that they are all primitive. > > I should add: this probably requires allowing new

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-05 Thread Ben Franksen
Am 04.07.20 um 23:43 schrieb James Cook: > On Sat, 4 Jul 2020 at 09:59, Ben Franksen wrote: >> Am 04.07.20 um 00:10 schrieb James Cook: >>>>> I'd say this is a feature, not a bug. If you mark the conflict between A >>>>> and B as resolved, *without* rec

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-04 Thread Ben Franksen
Hi James It was an interesting journey through the sea of patches! I think your construction is sound. I have somewhat skimmed over the more complicated proofs, but I trust they contain no grave mistakes, given that your exposition is otherwise very careful and precise. > Remark: In other

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-04 Thread Ben Franksen
Am 01.07.20 um 18:45 schrieb James Cook: >> Just to check I understood the idea (up to this point): roughly >> speaking, you represent "unrepresentable" states by formally commuting >> patches. >> >> That is, if we regard the primitive states as vertices and primitive >> (named) patches as edges

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-04 Thread Ben Franksen
Am 04.07.20 um 00:10 schrieb James Cook: >>> I'd say this is a feature, not a bug. If you mark the conflict between A >>> and B as resolved, *without* recording a new patch, then this means you >>> are satisfied with the resolution that reverts both changes. There is no >>> reason why pulling C

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-03 Thread Ben Franksen
Am 03.07.20 um 23:44 schrieb Ben Franksen: > Am 03.07.20 um 22:22 schrieb James Cook: >> I think I've found a new problem with Proposition 5, though. >> >> Suppose A, B and C are three mutually conflicting patches with >> starting context s. >> >> Suppose I

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-03 Thread Ben Franksen
Am 03.07.20 um 22:22 schrieb James Cook: >>> But yes, I realized after writing it that I never covered inverting >>> extended patches. >>> >>> Thinking about it more, I think I've found some problems. Let's say s >>> is the starting context of A and B, and A ends with a and B ends with >>> B. Here

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-03 Thread Ben Franksen
Am 03.07.20 um 05:22 schrieb James Cook: > On Thu, 2 Jul 2020 at 18:40, Ben Franksen > wrote:> The final chapter about the effect of extended patches and how > to >> resolve the conflicts they represent could use a bit of elaboration. For >> instance, though you refer to

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
The final chapter about the effect of extended patches and how to resolve the conflicts they represent could use a bit of elaboration. For instance, though you refer to the process, you haven't explained how (extended) patches are merged. I think you will need to introduce inversion for this. This

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
Am 01.07.20 um 05:09 schrieb James Cook: > Definition: We associate a primitive context to every context address > (and in particular to every extended context) (a, b, (Qi), X, Y) using > the following recursive algorithm. > > * If X=Y={}, then the context is a (=b). This is an embedded primitive

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
Am 01.07.20 um 05:09 schrieb James Cook: > The overall procedure is this: > > 1. Merge the individual patches to be permuted into a patch sequence > address (a, b, (Qi), (nj), X, Y). (You could merge a pair of adjacent > patches, the whole sequence of patches in the repo, or anything in >

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
> Definition: Let A=(a, b, (Qi), (nj), X, Y) be an patch sequence address > of length n (i.e. (nj) has n names in it). The /separation/ of A is a > sequence of n extended patches. Patch j in the sequence is the minimal > form of (a, b, (Qi), nj, X U {before}, Y U {after}), where {before} is > the

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
> Definition: A /patch sequence address/ is a tuple > (a, b, (Qi), (nj), X, Y), where a and b are (primitive) contexts, (Qi) > is a sequence of (primitive) patches going from a to b, nj is a sequence > of unique names of patches in (Qi), and X and Y are a partition of the > remaining names in

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
Am 02.07.20 um 00:37 schrieb James Cook: >> The construction works by inductively taking any pair of incommutable >> patches (in sequence, i.e. with a common middle state) and then >> "formally" commuting it. The new node is represented as that pair of >> patches. Is that, essentially, the idea? >

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-02 Thread Ben Franksen
Am 02.07.20 um 00:29 schrieb James Cook: > Definition: A /patch address/ is a patch sequence address where the > sequence (nj) has length one. > > Sorry, there are a lot of definitions, but maybe you missed that one? Oops. Yes, sorry. I was jumping around, trying to get a grip on the idea. >>

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 18:45 schrieb James Cook: >> Just to check I understood the idea (up to this point): roughly >> speaking, you represent "unrepresentable" states by formally commuting >> patches. >> >> That is, if we regard the primitive states as vertices and primitive >> (named) patches as edges

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
> Definition: A context address (a, b, (Qi), X, Y) is a /simplification/ > of a context address (a', b', (Q'i), X', Y') if X and Y are subsets of > (or equal to) X' and Y' and the sequence (Q'i) can be permuted so that > it first follows the patches in X' \ X from a' to a, then follows the >

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 18:39 schrieb James Cook: >> A well-known and quite natural way to identify the equivalence class of >> all patches that a given patch P can be commuted to, is to use the so >> called "minimal context". A minimal context C(P) for some patch P is a >> sequence of patches starting at

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 17:59 schrieb Ben Franksen: > Am 01.07.20 um 17:13 schrieb James Cook: >> On Wed, 1 Jul 2020 at 10:21, Ben Franksen wrote: >>> Am 01.07.20 um 05:09 schrieb James Cook: >>>> The context address /points to/ a context c if there exists a >>

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 17:13 schrieb James Cook: > On Wed, 1 Jul 2020 at 10:21, Ben Franksen wrote: >> Am 01.07.20 um 05:09 schrieb James Cook: >>> The context address /points to/ a context c if there exists a >>> permutation of (Qi) such that all the patches with names i

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 05:09 schrieb James Cook: > The context address /points to/ a context c if there exists a > permutation of (Qi) such that all the patches with names in X come > before patches with names in Y, and c is the after-context of the k-th > patch in the sequence (equivalently, the

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
I haven't fully digested everything you wrote but I guess a remark may be in order, lest you waste time on something that cannot be implemented efficiently. I am not claiming this is equivalent to what you aim at, but I think it is at least related. A well-known and quite natural way to identify

Re: [darcs-users] How to extend a patch theory to fully commute

2020-07-01 Thread Ben Franksen
Am 01.07.20 um 05:09 schrieb James Cook: > Example: Suppose a is the starting context (empty repository), Q1 > creates the file "foo" starting from a, Q2 creates the file "bar" > starting from there, and b and c are the contexts after P1 and then P2. > The address (a, c, [Q1, Q2], {}, {1, 2})

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-30 Thread Ben Franksen
Am 29.06.20 um 19:12 schrieb James Cook: >> Another problem is that even supposing commutation does not change prim >> patches, in darcs you still have conflictors. And conflictors >> /definitely/ have to change representation when we commute them: the >> merge-commute law obviously requires that.

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-29 Thread Ben Franksen
Am 29.06.20 um 16:51 schrieb James Cook: >> There is also more than just hunks. What about file renames? A file >> rename commutes with a hunk that changes the file, and in darcs this >> changes the hunk patch to refer to the renamed file. You need to change >> the internal representation to refer

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-29 Thread Ben Franksen
Am 29.06.20 um 13:46 schrieb James Cook: >> This in turn led me to the more general question of how to detect >> inconsistencies when exchanging patches between repos. The problem here >> is that darcs currently relies on global uniqueness properties that are >> quite easy to invalidate (e.g. by

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-29 Thread Ben Franksen
Am 29.06.20 um 12:53 schrieb James Cook: >> Converting existing repos to darcs-3 is unfortunately one of the things >> we havent't done yet. I have implemented a number of conversion schemes >> but they all fail in some situations. There are two hard problems to >> solve here: >> >> (1) What to do

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-29 Thread Ben Franksen
Am 29.06.20 um 03:54 schrieb James Cook: > I'm glad to hear about darcs-3. I was worried work on implementing > Camp had stopped completely. Yes, I am quite happy about that, too. It means we finally have an implementation of a patch theory that satisfies all required patch laws. We have upgraded

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-27 Thread Ben Franksen
Am 26.06.20 um 20:55 schrieb James Cook: >>> I've been reading about patch theory [0]. I *thought* what's supposed >>> to happen is this: >>> >>> * The effect of B' is the same as the effect of A. (i.e. create the file) >>> * The effect of A' is the same as the effect of B. (i.e. add "some text")

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-26 Thread Ben Franksen
Am 26.06.20 um 05:03 schrieb James Cook: >>> What I'd like to do is create a repository R1 with patches A and B, >>> and then look at the patches that result if A and B get >>> force-commuted. >>> >>> E.g. if I could pull just patch B and not A to a new repository, I >>> think that would do the

Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

2020-06-25 Thread Ben Franksen
Am 25.06.20 um 18:52 schrieb James Cook: > I'm trying to learn more about how darcs force commutes work. There is a reason we do not have such a command ;-) > What I'd like to do is create a repository R1 with patches A and B, > and then look at the patches that result if A and B get >

Re: [darcs-users] Learning darcs

2020-05-05 Thread Ben Franksen
Hi Tom Am 23.04.20 um 08:49 schrieb Tom Midgley: > In the learning material about darcs on http://darcs.net/Using/HunkEditor > there > is an example which used to be at > > |http://patch-tag.com/r/kowey/rambling-robot| > > which now a site about testosterone patches for ageing bikers > It

Re: [darcs-users] Darcs-Subversion bridge

2020-03-12 Thread Ben Franksen
Hi Henning Am 11.03.20 um 12:37 schrieb Henning Thielemann: > I want to contribute to a Subversion repository, but I want to edit > changes and run tests before committing, because in Subversion you can > hardly revert a commit. I have seen there were some ideas to bridge > Darcs to Subversion.

Re: [darcs-users] darcs patch: Setup.hs: allow use of darcs as a cabal subproject

2020-02-20 Thread Ben Franksen
I have fixed the email setting to patc...@darcs.net. Am 19.02.20 um 10:33 schrieb Ben Franksen: > It seems branch-2.14 has a wrong email setting. pEpkey.asc Description: application/pgp-keys ___ darcs-users mailing list darcs-users@osuosl.org ht

Re: [darcs-users] darcs patch: Setup.hs: allow use of darcs as a cabal subproject

2020-02-19 Thread Ben Franksen
It seems branch-2.14 has a wrong email setting. This should have gone to the tracker, possibly via darcs-devel? Am 19.02.20 um 09:52 schrieb Ben Franksen: > Note this patch is for branch-2.14, it will probably not apply cleanly to > screened. I propose we pull it anyway and resolve the con

[darcs-users] darcs patch: Setup.hs: allow use of darcs as a cabal subproject

2020-02-19 Thread Ben Franksen
Note this patch is for branch-2.14, it will probably not apply cleanly to screened. I propose we pull it anyway and resolve the conflicts. 1 patch for repository http://darcs.net/releases/branch-2.14: patch 7f9e8d76769e21fde94395a06d2b2a99cb57b5dc Author: Ben Franksen Date: Wed Feb 19 09:45

Re: [darcs-users] rebase pull/apply vs. pull/apply --rebase

2020-02-03 Thread Ben Franksen
Am 02.02.20 um 19:11 schrieb Ganesh Sittampalam: > On 28/01/2020 10:37, Ben Franksen wrote: >> It would be quite convenient to have a --rebase option for obliterate >> that automatically suspends all patches that depend on the one(s) you >> want to obliterate. > >&g

[darcs-users] rebase pull/apply vs. pull/apply --rebase

2020-01-28 Thread Ben Franksen
I have been thinking again about the UI design question for rebase: subcommand vs. option. What prompted me was the following scenario, which I encountered just now: Suppose you want to obliterate patch A. Perhaps it turned out that A wasn't such a good idea after all. But you also have another

Re: [darcs-users] force commuting in practice

2019-06-16 Thread Ben Franksen
anges. And on unsuspend of B;A it tells me there are conflicts but there are no conflict markups. For the test if used > darcs log -v patch f41bf21d0d6027ff8f9de1dbb3b6b64b098c953c Author: Ben Franksen Date: Sun Jun 16 14:15:25 CEST 2019 * bar hunk ./f 1 -foo +bar patch 16f117520aac3b17

Re: [darcs-users] removing --reply option from darcs

2018-11-07 Thread Ben Franksen
more maintainable! > > Guillaume > > El sáb., 13 de oct. de 2018 a la(s) 17:11, Ben Franksen ( > ben.frank...@online.de) escribió: > >> I am sending this to the users list to see if anyone is actually relying >> this feature because I would like to remove it

[darcs-users] removing --reply option from darcs

2018-10-13 Thread Ben Franksen
I am sending this to the users list to see if anyone is actually relying this feature because I would like to remove it. Darcs has since its early days supported a --reply option for the apply command. I think this feature has been meant for continuous integration. So when someone sends a patch,

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

2018-04-17 Thread Ben Franksen
Am 13.04.2018 um 10:19 schrieb Stephen J. Turnbull: > Benjamin Franksen writes: > > On 04/10/2018 08:34 AM, Stephen J. Turnbull wrote: > > > > Any user who understands what a ref is will say "a Darcs tag is > > > too a ref!" I think. > > > > Perhaps (but you won't, right?). > > I would, in

Re: [darcs-users] post 2.14.0 tasks / decisions

2018-04-14 Thread Ben Franksen
Am 13.04.2018 um 23:03 schrieb Guillaume Hoffmann: > * decide if include DarcsDen as part of Darcs' repository to avoid bitrot A bold move. I understand the motivation but I am not comfortable with the idea of adding external and to a large extent completely unrelated code to Darcs. I think with

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

2018-03-29 Thread Ben Franksen
Am 29.03.2018 um 10:08 schrieb Stephen J. Turnbull: > Ben Franksen writes: > > If yes, then I begin to understand why as a Darcs user I found it so > > difficult to become familiar with git. Because this concept of a "ref" > > has no (user visible) counterpart in

Re: [darcs-users] preparing a 2.14 release

2018-03-28 Thread Ben Franksen
Am 26.03.2018 um 17:38 schrieb Guillaume Hoffmann: >> IMO the two rebase bugs I stumbled over (http://bugs.darcs.net/issue2581 >> and http://bugs.darcs.net/issue2575) must be fixed before a release. > > That would be great. I have fixed them both, ha! > I am thinking about releasing 2.14.0 on

Re: [darcs-users] String encoding issue

2018-03-24 Thread Ben Franksen
Am 22.03.2018 um 12:40 schrieb Stephane Bortzmeyer: > On Thu, Mar 22, 2018 at 11:29:54AM +, > Eric Kow wrote > a message of 157 lines which said: > >> Does setting DARCS_DONT_ESCAPE_8BIT to 1 help? > > Ah yes, thanks. I then discovered >

Re: [darcs-users] Resurrecting a file?

2018-03-24 Thread Ben Franksen
Am 22.03.2018 um 11:13 schrieb Stephane Bortzmeyer: > I am wondering if there is a simply way to ressurect a file which has > been deleted some times ago. Today, I do a darcs changes (if I > remember the file name) or a darcs test (if I don't), find the last > patch where the file existed, then do

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

2018-03-24 Thread Ben Franksen
Hi Steve sorry for (again) responding at length. You gave me yet more ideas... Am 22.03.2018 um 01:15 schrieb Stephen J. Turnbull: > Ben Franksen writes: >> My experience with git tells me that when I make a clone what I get >> is /not/ identical to upstream. > > I may

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

2018-03-20 Thread Ben Franksen
Am 20.03.2018 um 10:33 schrieb Stephen J. Turnbull: > Ben Franksen writes: > > Am 19.03.2018 um 09:12 schrieb Stephen J. Turnbull: > > But git chooses to not clone all the refs by default and there is a > > reason for that because it would have to pull all the referen

Re: [darcs-users] referencing in-repo branches

2018-03-07 Thread Ben Franksen
Am 07.03.2018 um 22:10 schrieb Wolfgang Jeltsch: > Am Mittwoch, den 07.03.2018, 19:11 +0100 schrieb Ben Franksen: >> [...] > > This sounds just great. I would love to see this implemented. > > Please keep up the good work! Hi Wolfgang Thanks for the encou

[darcs-users] referencing in-repo branches

2018-03-07 Thread Ben Franksen
Hi All the recent discussions here gave me a much better picture of what kind of features we should strive for when we add in-repo branches. But perhaps I should not (yet) talk about branches. Let us talk instead about "patch sequences". The way Darcs works today is that it knows of exactly one

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

2018-03-07 Thread Ben Franksen
nded up having to work through a lot of > stuff to figure out what I think about the various VCSes, and record > it here for those interested in understanding why git seems so wrong- > headed to many users, and yet persists in its idiosyncratic ways. I'm > sure there will be many points of disa

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

2018-03-05 Thread 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

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

2018-03-05 Thread Ben Franksen
Am 05.03.2018 um 01:47 schrieb Karl O. Pinc: > On Sun, 4 Mar 2018 23:23:33 +0100 > Ben Franksen <ben.frank...@online.de> wrote: > >> What made me re-consider >> the idea was that I found I like the way mercurial automatically >> creates a branch

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

2018-03-05 Thread Ben Franksen
Am 05.03.2018 um 03:40 schrieb Evan Laforge: > On Sun, Mar 4, 2018 at 2:46 AM, Ben Franksen <ben.frank...@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-minim

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

2018-03-04 Thread Ben Franksen
Am 04.03.2018 um 21:12 schrieb Karl O. Pinc: > On Sun, 4 Mar 2018 12:04:01 +0100 > Stephane Bortzmeyer wrote: > >> * no branches. Don't add them! The one-branch-per-repo model is much >> better > > Thinking out loud here. > > If I had to vote today I'd say: > > -1 on

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

2018-03-04 Thread Ben Franksen
Am 04.03.2018 um 05:03 schrieb Karl O. Pinc: > On Sat, 3 Mar 2018 18:36:32 -0800 > Evan Laforge wrote: > >> On Sat, Mar 3, 2018 at 6:26 PM, Karl O. Pinc wrote: >>> This being so, I'm curious why a darcs user would choose >>> git over mercurial. >> >>

Re: [darcs-users] preparing a 2.14 release

2018-02-07 Thread Ben Franksen
Am 08.02.2018 um 00:22 schrieb Guillaume Hoffmann: > Ganesh has published some unscreened changes at > http://bugs.darcs.net/patch1628 but said today on IRC that the windows > issues still require work. I was planning to take a closer look at these changes. > Maybe do you have a powerful enough