bobbyBill · HackerTrans

vor 14 Jahrendiscuss

Even without shared working directories, with the current branch as a dir workflow, you have no easy way to see what branches you have, how they relate, nor to express how they should relate (which one should follow which other one). For instance, this means that if I open a new branch on my public repository, there's no automated way for people pulling from my older branch to notice that fact. To me, it is a more compelling but rarely stated argument for in-vcs branching.

bobbyBill

vor 14 Jahrendiscuss

You can, you just use `darcs record --ask-deps`. There's also the idea of allowing some kind of test to infer more dependencies for you at record time.

bobbyBill

vor 14 Jahrendiscuss

Don't forget that there are two kinds of dangerous in a vcs: code-dangerous and repo-dangerous: stuff that can give you a working repo containing code that does not work, and stuff that can give you a non-working repo, or changes between repos that are tracked inconsistently. Cherry-picking (i.e. creating a version that has not been seen by a developper before) is as code-dangerous with darcs as it is with git. Commit and merge are also code-dangerous. On the other hand, in darcs it is not repo-dangerous: you don't have to worry about merges versus cherry-picks, a repo's final state is only defined by which patches you've pulled. This is the kind of consistency that git does not give, and that makes git rebase repo-dangerous. darcs' cherry-pick is no more dangerous than merge, while git's is in fact more dangerous.

It is quite common to have people come to #darcs asking how to reorder patches. The answer to that is "why would you want to do that?" To darcs, the order in which the patches are stored in the repository is a transparent implementation detail, and there's no command to change that. Darcs users are not constantly reordering patches, they're just enjoying a bit more freedom on pull. In general, if you don't use commands marked as unsafe such as unpull, each repository is honest about the order in which it pulled patches: darcs will simulate patch reordering to compute merge results, but won't change the order of patches in the repository.

There's one "patch theoretical" thing which git does better than darcs (and a lot of practical things), which is that it tracks more explicitely which stuff was pulled from where when. That information is neglected by darcs, which cares more about when stuff was originally written, and it should be tracked somewhere. Still, this seems easier to add to darcs than adding darcs' freedom of workflow to git, for which, as far as I can tell, you'd have to embrace the patch-centric view of darcs.

comments