[darcs-devel] What should be in a branch?

Ben Franksen ben.franksen at online.de
Sun May 9 09:28:24 UTC 2021


Am 08.05.21 um 18:37 schrieb Ganesh Sittampalam:
> Apologies, this is another message from early April I appear to have
> missed completely.
> 
> On 06/04/2021 08:39, Ben Franksen wrote:
> 
>> Would it be a great loss if we followed the git way, that is, have only
>> one pending and one rebase per repo and not one per branch?
>>
>> Pending changes can be (temporarily) recorded and put on a new branch.
>> Similarly, a rebase in progress can be reified and put on a new branch.
>> We could offer the user to do these things for them when they want to
>> checkout a different branch, prompting the user for a branch name. For
>> pending, we could also emulate git by trying to transfer
>> (record+pull+unrecord) pending to the new branch and fail only if we get
>> conflicts or if pending depends on patches not contained in the other
>> branch.
> 
> I think there _should_ be only one pending per repo. Pending relates
> fundamentally to the working tree. If we had one pending per branch,
> then you could add a file X on branch A, switch to branch B and record
> the addition of file X, then switch back to branch A and have X in
> pending even though it would no longer be in the working tree.

Good point. Yes, I agree there are good reasons to regard pending as
being more related to the working state as to the recorded state.

> As you say, we would have to do something to migrate it to a different
> recorded state. I think we already have the machinery and the UI to do
> it cleanly: it's the same thing as happens when we pull or obliterate
> patches.

Correct.

> Rebase I view slightly differently. Taking your idea about reifying a
> rebase and putting it on a new branch one step further, can we not
> simply treat the original unreified rebase as part of the branch state?
> For example maybe we could store the rebase in hashed_inventory directly?

That was my original idea, but I became doubtful, which is why I was
seeking your input on this.

> I think a good fallback position for rebase would be to treat it the
> same way as pending, i.e. just treat the branch switch as a mixture of
> pull/obliterate. But if we can do better I think it would be a nice feature.

Okay, thanks. That was really helpful.

Could you also comment in a similar way on the last piece of state which
is the unrevert patch?

To give you an update on how this currently works: we store it as a
patch bundle in which the last patch contains the (unrecorded i.e.
reverted) changes that we may later want to unrevert. (An equivalent way
to store it would be as an inventory.) The bundle gets updated (1) when
we revert changes (by adding these changes to its last patch) and (2)
when we /remove/ patches from the repo: either we can commute out the
removed patches past the the unrevert state or else the unrevert state
will be reset to nothing (this is the "this will make unrevert
impossible" warning). Effectively this means that the unrevertable
changes always directly fork off from our patch history with no
intervening patches:

 repo = ...->P4->P3->P2->P1->pending
                 |
                 v
             Punrevert

Cheers
Ben
-- 
I would rather have questions that cannot be answered, than answers that
cannot be questioned.  -- Richard Feynman




More information about the darcs-devel mailing list