Re: so long and thanks for all the darcs

Am 04.03.2018 um 21:12 schrieb Karl O. Pinc:
> On Sun, 4 Mar 2018 12:04:01 +0100
> Stephane Bortzmeyer <[email protected]> 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 branches in the default darcs
> 
>   Perhaps being able to point to various repos in the
>   darcs configuration and call them "branches" might be
>   cool.  But come to think of it it's probably better
>   to just call them repositories and add options to,
>   say, the diff sub-command to be able to handle
>   other repositories.  Maybe provide some short-hand for
>   repo naming and call that short-hand label a "branch"
>   name.  Seems like checking out a "branch" is just
>   switching your defaultrepo.  
> 
>   Anyway, adding what
>   amounts to a lot of syntatic sugar into the default
>   darcs does not appeal.  One way to do something is always
>   less confusing than many ways to do the same thing.

I was always thinking along similar lines. 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. Of course, a mercurial user
would correct me at this point: it doesn't matter if the patch conflicts
or not, it's just that the histories diverge. 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.

So I thought: what if darcs did /not/ by default create conflictors, and
instead puts the conflicting patch on a newly created branch? This would
give me the choice to /postpone/ what to do: I don't have to resolve
conflicts immediately but can do it at my leisure. Or perhaps I decide I
don't want to allow the conflict after all and rather rebase my local
changes. Or do a mixture of both. In any case you'd rather want to avoid
doing conflict resolution when you are in the middle of finishing
something else.

The automatic branch creation when pulling conflicting patches is a bit
like what 'darcs rebase pull' does but with an important difference:
suspending a patch commits yourself to changing its identity; local
patches that become suspended aren't first class patches any more: you
cannot switch to the "suspended patches branch". In contrast, branches
are fully symmetric: none is better than the other, patch identities
remain unmodified, and you can switch between them easily.

Branches would also allow us to do many of the "destructive" operations
less dangerously by default. For instance, darcs could create a branch
when you amend a patch: the old version of the patch simply lives on in
its own branch. If you later find the amend was a mistake, easy, just
switch to the other branch. Similarly for obliterate, and BTW much
easier to work with than obliterate -O which has a tendency of slowly
filling up your top directory with patch bundles. This would also allow
us to re-implement unrevert in a cleaner way: during a revert we just
gather all the changes into a new patch and afterwards put it in its own
branch. Unrevert can now choose between any number of unrevert-branches
and you no longer will be asked "warning: this will make unrevert
impossible, proceed?".

These are all pretty raw ideas at the moment, none of it is implemented.
There are lots of open questions regarding UI design etc.

Cheers
Ben