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

Ganesh Sittampalam ganesh at earth.li
Sat May 8 16:37:28 UTC 2021


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.

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.

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?

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.

Cheers,

Ganesh


More information about the darcs-devel mailing list