[darcs-users] currently preferred way to import history from Git

[Ivan Zakharyaschev]

2015-01-22 13:16 UTC+03:00, Ivan Zakharyaschev <imz at altlinux.org>:

> Actually, after I make the transition to darcs, I'm thinking about a
> workflow with a reduced number of branches (no intersection branch
> AB), so I won't need a working darcs directory for AB. Does it make
> sense?
>
> Say, A is a feature I'm working on, and B is some implementation aspect.
>
> (In Git, I had to have the AB branch to avoid the hassle of
> cherry-picking a new patch from either A and B, and making sure that
> it is clear from the history that there is a single patch which is
> relevant for both A and B.)

I want to add a clarification about my annoyance with Git:

if I have a sequence of such A1, A2, ... branches, and B1, B2, B3, ...
with the idea that A1 is a subset of A2, and so on, and B1 is a subset
of B2, and so on, then it is quite tiresome to maintain the history
graph clean:

after I add a patch to the intersection of A1 and B1 (A1B1), I have to
rebase the set of changes A1B1..A1 onto the new state of A1B1, and
then A1..A2 onto the new state of A1, and so on (you get the idea).

What is annoying is that I can't postpone this procedure for later,
because a partially rebased history with many branches looks weird:
some heads are updated, but some are left attached to the old tree,
and you don't get the idea of each branch being a superset of some
other one. With darcs, it would at least seem not to be so weird
because you are not forced to think about the non-rebased branches as
long independent branches, but rather a set merely lacking just a few
new patches.

> When I'm hacking the implementation aspect B, I plan to work in the
> darcs working directory "B", then pull the patches relevant for A (by
> interactively selecting them):
>
> cd ../A
> darcs pull ../B
>
> (and a similar situation will arise whenever I am working on feature
> A, and have touched--among other changes--the aspect B of the
> implementation, then I will want to pull the relevant subset of new
> changes into B).
>
> (There is a complication in this picture although: not to review the
> patches I have already decided on, I should have a dir for the last
> reviewed state of B, and another one--the actual working dir for B,
> and:
>
> cd ../A
> darcs pull ../B.working --complement ../B.reviewed
> # if successful then
> cd ../B.reviewed
> darcs pull --all ../B.working

-- 
Ivan