Loup Vaillant wrote:

2008/6/3 Darrin Thompson :

...

<--cut--> What's the appeal of this? I personally love git, but I thought all the cool kids at this school used darcs and that was that.

Disclaimer: I'm no expert, this is what I've heard. Anyone please confirm or deny the following?

Basically, git is waaay faster than Darcs on a number of use cases.

Other reason can be "git rebase". Of course there is a question how good practice it is ... but it is being used. Peter.

Aaron Denney wrote:

On 2008-06-03, Peter Hercek wrote:

...

Loup Vaillant wrote:

...

2008/6/3 Darrin Thompson :

...

<--cut--> What's the appeal of this? I personally love git, but I thought all the cool kids at this school used darcs and that was that. Disclaimer: I'm no expert, this is what I've heard. Anyone please confirm or deny the following?

Basically, git is waaay faster than Darcs on a number of use cases. Other reason can be "git rebase". Of course there is a question how good practice it is ... but it is being used.

Darcs patches are pretty much an implicit rebase.

You cannot push patch B if it depends on patch A without also pushing A. And darcs currently does not alow you to reorder B before A (which is what git rebase actually does). Git rebase works quite well even in cloned repositories. See: http://bugs.darcs.net/issue891 Some discussin about it is also here: http://lists.osuosl.org/pipermail/darcs-users/2008-February/011564.html When the issue is fixed then darcs will be really patch based and will become the ultimate DSCM :-)

Aaron Denney wrote:

This is drifting off-topic, but... On 2008-06-03, Peter Hercek wrote:

...

...

Darcs patches are pretty much an implicit rebase. You cannot push patch B if it depends on patch A without also

Aaron Denney wrote: <--- cut ---> pushing A. And darcs currently does not alow you to reorder B before A

True. This is a *feature* not a bug. You shouldn't be able to do this automatically, because it can't be done right. You need to do this sort of thing manually. If you don't, the heuristics used will bite you at some point. When they do commute, there is no problem.

Sorry, I did not intend to indicate it should be done without doing the reordering first (by providing manual conflict resolution).

...

Git rebase works quite well even in cloned repositories.

Meh. It can, if you're really really lucky.

Actually you are probably right, I needed to use a non-complicated workaround once (but I did it only about two times!). I might have been just lucky. I liked though that it did tell me what was wrong, in contrast to mercurial queues which just replicated both original branch and the rebased branch (so I finished with two copies on both sides at the end :-( ). <--- cut --->

Rebasing is doable in git as a one-repository operation because each repository has multiple branches. As darcs has one repo per branch, it fundamentally needs to be done in multiple repos.

There are naturally two repos, upstream, and your-feature-development.

your-feature-development has a patch A that you want to rebase.

What you should do is pull upstream into new-tracking, then pull patch A from your-feature-development into new-tracking.

If it applies with no problem, great: mv your-feature-development your-feature-development-old; new-tracking your-feature-development. Of course, in this case, you could have just pulled into your-feature-development. If there weren't any other patches to save in the old your-feature-development, you can delete it instead of moving it.

When there is a conflict, then you need to handle it somehow. Neither git nor darcs can do it automatically. You can just record the merge conflict and your resolution. This keeps repos that pulled from you valid, but this won't give you the "clean history" that you presumably want. So you need to combine the merger and cleanup into a new patch with the same log message, etc. It's true that git does make *this* process very nice.

Ok, in such a simple case darcs can preserve the message too if the repository is not cloned (and you indicated that it does not really work with cloned repositories in git - I'm not an experienced git user). Just pull to the original repository and use amend-record to resolve the conflict and the message will be preserved. So I would tell that for *this* *simple* case darcs is better. But what about this git rebasing option? How to do it more easily (than the solution I know and I described it later) in darcs? using "git-rebase --onto master next topic" to get from: o---o---o---o---o master \ o---o---o---o---o next \ o---o---o topic to: o---o---o---o---o master | \ | o'--o'--o' topic \ o---o---o---o---o next This is the reason why I mentioned reordering depending patches AB to BA (with manual conflict resolution) would be needed in darcs to support (I believe a better) alternative to git rebase. I do not know how to do this in darcs (without doing manual addition of "topic" changes with gnu patch utility in a new darcs repository clone which would not have "topic" changes (and "next" changes as well) pulled in and throwing avay the old one at the end).

There is one thing that git rebase does easily (and correctly) that darcs doesn't do nicely: rewriting history by merging commits "prior" to the head. I put prior in quotes, because darcs doesn't preserve history in the first place. I don't find that a compelling use, as opposed to maintaing topic branches.

I do not know what you mean here. Can you point me to some example? I hope that this is not too off-topic for haskell cafe ... and so far I believe this is not a flame war :-) I just like that Bertram's code exists and I think it (as well as git) should not be dismissed, since AFAIK there is more than performance to git as well as there is more to darcs than it not imposing patch order on us (which is the darcs feature I like). Peter.

On 2008-06-04, apfelmus wrote:

Peter Hercek wrote:

...

But what about this git rebasing option? How to do it more easily (than the solution I know and I described it later) in darcs?

using "git-rebase --onto master next topic" to get from: to:

o---o---o---o---o master \ o---o---o---o---o next \ o---o---o topic

o---o---o---o---o master | \ | o'--o'--o' topic \ o---o---o---o---o next

This is the reason why I mentioned reordering depending patches AB to BA (with manual conflict resolution) would be needed in darcs to support (I believe a better) alternative to git rebase.

I don't understand (probably because I haven't use either dvcs).

Either the changes in the next->topic path don't depend on the changes in the fork->next path. Then, the patches commute and it's no problem for darcs.

Right. Then

...

o---o---o---o---o master \ o---o---o---o---o next \ o---o---o topic

is not a good model for what darcs has. What it has is more like

...

o---o---o---o---o master |\ | o---o---o---o---o next \ | o---o---o--------+ topic

The patches in "topic" that are in "next" are indepent of the ones that aren't in "next", so it's another (virtual) line-of-development, that darcs can lazily construct as needed. These lines-of-development are similar to branches of git that have been merged, but you also have access to the "unmerged" versions until a patch comes in that depends on the merger. If I commit three new features that don't interact, a darcs repo will essentially look like: ---- topicA - / \ history --- topicB --+-- \ / ---- topicC - Where the merger is "virtual". Darcs will implicitly linearize this to any of history --- topicA --- topicB --- topicC --- history --- topicA --- topicC --- topicB --- history --- topicB --- topicA --- topicC --- history --- topicB --- topicC --- topicA --- history --- topicC --- topicA --- topicB --- history --- topicC --- topicB --- topicA --- /as needed/. git constructs one of these, based on how you did the commits, and gives you ways to alter it to the others.

Or the next->topic path relies on features from next that are not present in master . But then, you're screwed anyway

Yep.

and should merge some parts from next into master so as to advance the point where master and next fork.

That's one solution. Of course, darcs doesn't have semantic dependency, but syntactic dependency. (You can add extra dependencies to model semantic dependencies, but you can't take away the syntactic dependencies.) Another solution, if there's syntactic, but not semantic dependencies, is to manually use patch and diff to get 90% there, and then cleanup and record. -- Aaron Denney -><-

On 2008-06-04, Peter Hercek wrote:

But what about this git rebasing option? How to do it more easily (than the solution I know and I described it later) in darcs?

using "git-rebase --onto master next topic" to get from: o---o---o---o---o master \ o---o---o---o---o next \ o---o---o topic to:

o---o---o---o---o master | \ | o'--o'--o' topic \ o---o---o---o---o next

apfelmus answered this. I might expand on his reply.

...

There is one thing that git rebase does easily (and correctly) that darcs doesn't do nicely: rewriting history by merging commits "prior" to the head. I put prior in quotes, because darcs doesn't preserve history in the first place. I don't find that a compelling use, as opposed to maintaing topic branches.

I do not know what you mean here. Can you point me to some example?

Letting capitals be commits, and lowercase be trees at the point of these commits. Suppose your history is: A -> B -> C -> D | | | | a b c d And that B somehow doesn't make sense except with the additional changes in C. You don't want to deal with this, or have anyone see B. All it does is clutter up the history. So you want to expunged it from the history. git rebase can rewrite this to A ------> C' -> D' | | | a c d Doing this in darcs would require unrecording B and C, and then rerecording C'. But, if D is in the repo, then it is likely that B and C can't be commuted past it to be unrecorded. (If they can, no problem!) Unrecording D (and possible E, F, G, etc.) lets you do this, but if you then pull it back from another repo, it will depend on B and C, and pull these in, which are now doppelgangers of C'. Not having used darcs 2, I'm not sure if that's still quite so fatal, but it remains bad news AIUI. The bottom line is that darcs is a tool for managing sets of always existing patches. and ordering them lazily, as needed. In particular, no history generally exists, unless each patch depends on exactly one previous. It has a "differential" view of software development, in that the changes, and not the sum at each point matter (though of course, the current sum does matter.) On the other hand, git is a tool for managing (and munging) histories of development in many weird and wacky ways. It has an "integral" view of software development, the changes are lazily derived from the saved state at each point, and are strictly ordered even when they're independent. It can, when needed, work with these changes to accomplish fairly interesting history-altering tasks, but as soon as they're used to construct a new history, they're discarded. (Yes, git uses deltas, but this is "merely" an optimization.) The two models are dual to each other in many ways. -- Aaron Denney -><-

Darrin Thompson wrote:

On Sun, Jun 1, 2008 at 2:44 PM, Bertram Felgenhauer wrote:

...

I'm pleased to announce yet another tool for importing darcs repositories to git. [...]

What's the appeal of this? I personally love git, but I thought all the cool kids at this school used darcs and that was that.

For myself, git-darcs-import itself is an opportunity to learn more about both darcs and git. It wasn't meant to be argument in the git vs. darcs discussion, although it was inevitable that it would be seen as such. I really like darcs' concepts, but in my opinion, darcs doesn't get enough power out of the theory of patches to really shine so far. This is a hard problem, and I can't offer solutions. Ideally, you'd have semantic patches which just commute with virtually all other patches because they "know" what they are about. The only thing that darcs offers in that direction - besides handling conflicts, mergers and undos gracefully, which is quite useful in itself - is a keyword substitution patch type. In the meantime, I prefer git to darcs, mainly because I'm sort of attached to seeing the development history, i.e. I prefer to think of patches as (partially) ordered instead of being a cloud of patches that darcs uses as a model. Bertram