On 4/23/2011 4:14, Orchid XP v8 wrote:
> Seems more like because it's so difficult to merge two files,

It's no more difficult in git than in darcs. It's exactly the same process. 
You apply one set of diffs, then the other. If there are no conflicts, 
you're done. If there are conflicts, you fix them, and you're done.

If there's a branch called "newstuff" and I'm working on "master", and I 
want to merge in the changes from newstuff, I say

git merge newstuff
git commit

If file ABC has a conflict in it, I say

git merge newstuff
vi ABC
git add ABC
git commit

> after you've
> done it you have to save it to prevent you having to redo all that complex
> hard work.

Yes.  Except it's exactly as hard and complex as in Darcs.

> And in the process, all change application is forced to become
> strictly linear.

git doesn't record changes, so no, change application isn't forced to become 
linear.

> Apparently this doesn't stop people working on the Linux kernel. But it
> seems really clumsy to me.

It seems clumsy because you keep thinking git is recording changes. You keep 
thinking of "changes" instead of "versions".

>> I'm not sure I'd want to check out something from Darcs that has a
>> quarter million patches in it and wait for Darcs to apply them all one
>> by one. How well does it handle that?
>
> You're aware that Darcs keeps a cached copy of the latest state of all the
> files, so it doesn't have to recompute them, right?

Sure.

> Last time I tried downloading the repos for GHC, it was dominated by network
> latency. Processor usage was almost non-existent. It just takes a long time
> to shift gigabytes of data over a slow ADSL link. Just as it would if I had
> downloaded a Zip file of the source code with no history data at all.

Yep. But you only got the latest version. If you wanted to get every tag, 
you wind up copying all those files again anyway.

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

Post a reply to this message