[darcs-users] some questions about branching

Eric Kow kowey at darcs.net
Mon Apr 12 10:30:43 UTC 2010

Hi Stephen,

I hope this three-month-late reply isn't a problem.  I had made a note
to myself to just "write down uses for remote branches" from your mail,
but upon re-reading I realised I did not understood your mail well
enough.  So I was hoping for some clarifications.

Eric wrote (around 3 Jan):
>> I just had a thought on one principle we could adopt that could help
>> us preserve this simplicity.  Johan: since you're an active user of
>> branches, could you comment on the following idea?
>>  Darcs should never implement 'remote' branches.

I should mention that having used Git (and github) some more I have
warmed somewhat to the idea of remote branches.  That said, I'm *still*
nervous about not being able to do it in a way that keeps Darcs simple
and friendly [at least for the workflows it currently supports]. 

That nervousness was why I was hoping we could get away with just local
branches.  Now I suppose that wouldn't actually be making things that
much simpler and that if we were going to do branching at all, we might
as well just go all the way.  Hopefully we *can* pull this off if we're
sufficiently thoughtful about it.

On Sun, Jan 03, 2010 at 01:47:31 +0900, Stephen J. Turnbull wrote:
> At the lowest level, you're saying it matters whether the patch I need
> is currently stored locally or in some other repository.  That's
> clearly a mostly bogus distinction.[1]  Copy the patch and be done
> with it, OK?

For more context, I later replied saying that the only thing I was
concerned about was opening up a can of UI worms, that adding all the
necessary concepts/distinctions/operations to support branches may make
Darcs more difficult to understand and use.

> The next level problem is that if your VCS supports colocated
> branches, you might commit to the "wrong" branch because you forgot
> which one you're in.  Fixing this is just a rebase (and maybe
> splitting the first patch).  Well, hey, isn't Darcs the world's best
> tool for rebasing, and no slouch at splitting up patches?  And note
> that this can surely happen without *remote* branches.

In the case of local branches, I think I'd agree that it's just a
question of pushing/pulling patches.

For remote branches, don't we run into the usual advice of not
performing git rebase (or darcs obliterate, or darcs amend) on
already-published work?

> Finally, when pushing or pulling you could indeed make a big mess by
> increasing the number of branches and silently switching to the
> "wrong" one.  That's a real problem for Darcs, I think, just as for
> git, but git's solution (and Mercurial's, and Bazaar's) should be
> applicable here: by default, remote operations are only permitted if
> they are fast forwards.  (I'm not sure exactly what "fast forward"
> means in the context of Darcs, but to the extent that it's somewhat
> fuzzy that's precisely because Darcs knows how to handle most
> situations, I think.)

About fast-forwards, reading
gives me the impression that a fast-forwards in Darcs is just the case
of pulling patches where "our" history is just a prefix of "their"

  us   p1 p2 p3
  them p1 p2 p3 t4 t5 t6

In that case, no patch commutation happens; we just grab and apply.  On the
other hand, our working directory changes (on top of p3) would have to commuted
past the new patches.

A less simple case would when we have changes of our own

  us   p1 p2 p3 u4
  them p1 p2 p3 t4 t5 t6

In which case we would do some patch inverse and commutation work so that we
could pull t4..t6 on top of { p1, p2, p3, u4 } instead of just { p1, p2, p3 }.
This would result in a repository that looks like this

  us+them p1 p2 p3 u4 t4' t5' t6'

where t4'..t6' are the result of commuting inverse(u4) past t4..t6

> [B]y default, remote operations are only permitted if
> they are fast forwards. 
> In other words, Darcs is only allowed to increase the number of branches in
> the target repo if the user specifies the branch to add *and* some kind of
> "new branch" option.

I'm a bit confused here.  What do fast-forwards have to do with the number
of branches?

In "remote operations are only permitted if they are fast forwards", I
understood something that you can only push patches on to repositories whose
history is a prefix of ours (like above, just flipped).

Whereas in the second sentence, I think you're talking about a UI scheme
to discourage branch proliferation.
> I can think of one use case where pulling a remote branch would be
> very useful.  That is the case where bootstrapping your project is
> very expensive.  The workflow here is to create a repository in one of
> the usual ways, and bootstrap it.  Now, if you want to test someone's
> changes, instead of cloning their branch (moderately to very expensive
> in a big tree) and bootstrapping (very expensive), you simply pull the
> delta to their branch into your "build&test" working tree and remake
> the changed files.

How would this be different from the current Darcs equivalent of just
pulling from a remote repository (as opposed to a branch within that

Does it matter what you meant by bootstrapping a project?  I thought you
were speaking informally saying something like "do some arbitrary
operation foo [configure, make] to get the working dir to some arbitrary
useful state [can run make test]"

>  > > Branches should be strictly a personal affair, something a hacker would
>  > > use to work on multiple features at the same time, or a maintainer to
>  > > keep track of a bunch different patch sets; but NOT for a project that
>  > > wants to publish multiple branches (they'd have to do it the old
>  > > fashioned way).
> I use git to synchronize multibranch repositories across several hosts
> all the time, and I just don't see a problem, as long as I don't
> rebase.  In fact, in a couple of cases I've had several wildly
> divergent versions, and I just pull the branches into one repo from
> wherever they might be, and mix and match with cherry-picks and merges
> until I've achieved a set of sane up-to-date branches.  I see no
> reason at all why Darcs shouldn't be even more efficient for this kind
> of thing.

Thanks for all the advice,

Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100412/1fc47ea1/attachment.pgp>

More information about the darcs-users mailing list