On 4/21/2011 2:35, Invisible wrote:
> The Darcs workflow. I download the source code, make a small edit to it, ask
> Darcs to record that, and send the changes to the developers. They add it to
> the central repo, which checks whether the bit I just edited has changed
> since I got my copy. If not [which is quite likely], the change is added to
> the central repo. Done.

OK. All the confusions you think you're seeing in git are due to Darcs just 
not being able to do what git does.

When Darcs gets a merge conflict, it just doesn't apply *either* patch.

"Darcs escapes this problem by ignoring those parts of the patches that 
conflict."

Obviously, if Darcs isn't going to try to fix the patches for you, it's a 
lot easier to record a bunch of conflicting patches. The equivalent in git 
is to pull in changes from other repositories and then not trying to update 
your working directory to include the changes. Trivial one-liner that always 
works.

"If the conflict is with one of your not-yet-published patches, you may 
choose to amend that patch rather than creating a resolve patch."

And that's exactly what the "git merge" command does. It takes your patches, 
and someone else's patches, and merges them together. It's a separate step 
because, unlike Darcs, git supports having more than one "pristine" in the 
same repository. If you only have one branch in git, it's as trivial as only 
having one repository in Darcs.

"This is how a project with many contributors, but every contribution is 
reviewed and manually applied by the project leader, can be run." This is 
the bit about sending email you were talking about. git can work that way, 
and the terrible "merge" problems you're talking about are handled the same 
way: the guy getting the patches fixes the merge.

What Darcs apparently can't do is support any way of doing distributed 
development with an authoritative repository *without* someone dedicated to 
fixing the merge conflicts. That's where the whole rant you're talking about 
came from. If you have someone who is going to look at your changes (i.e., 
if I am CTO and I want to build a new release or something) then the whole 
"fast-forward merge with a rebase" dance is unnecessary and indeed 
counterproductive, as it loses the history of the change (in the same sense 
that unrecording a bunch of changes and re-recording one big change in Darcs 
loses the history).

I'll grant you that Darcs is definitely simpler, but I think it's less 
capable also, and that's the primary place the simplicity comes from. The 
Darcs replace command is interesting, but I'm not sure how well that would 
work in practice, especially in languages with complex scoping.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message