On 4/21/2011 13:07, Orchid XP v8 wrote:
> Then yeah, you'd have to construct two versions of the repo, just like you
> would with any other version control system.

Except git. Because git doesn't store diffs, it stores files. :-)  So it's 
trivial for git to run whatever you want against two different versions of 
the files.

> Man, version controlling a multi-GB ISO image sounds like a barrel of
> laughs. o_O

That's one of the reasons why people like centralized servers.

>>>>> and doesn't even figure out which files changed.
>>>>
>>>> Yes it does.
>>>
>>> Then why do you have to manually tell it which files to commit?
>>
>> Because maybe you don't want to commit all your changes in one step.
>
> So you have to manually remember what you changed?

No, of course not. Are you even reading what I'm writing?  Why would the 
fact that you tell git what changes you want to commit with one command then 
actually commit those with a second command mean that git can't tell what 
you changed?

> I much prefer the way Darcs does it (i.e., prompt you for which
> changes you want to include in this particular commit).

I prefer the GUI, actually. Much easier to pick out various commits to commit.

>>> not sure what you mean by "Darcs needs you to do that all in one step".
>>
>> I mean that gathering up the changes and committing them sounds like a
>> single step in Darcs.
>
> A single interactive step, yes.

Which means you can't (for example) stop in the middle when you realize you 
forgot to make one of the 30 changes you want to commit to fix something in 
particular. You have to start over.

> So Git has a GUI tool that lets you do what Darcs does natively?

It's native to git too. You get to use the command line or a gui. You're 
really not actually reading what I'm writing, are you?

> Except that usually 200 people will be editing 200 different parts of the
> repository.

And if that's the case in git, then you have no trouble merging things when 
and as you want them.

>> Basically, you say "go look at the changes I made since I branched off
>> the upstream repository, then apply those same changes to the new head
>> of the upstream repository, and submit *that* as the new commit."
>
> The Darcs model is "the bugfix for #5326 is *this* alteration". You can then
> apply that to whatever you want. (Unless the modified bit is altered, of
> course.) The Git model seems to be

The git model seems to be something you're still fully unfamiliar with.

 > to do lots of extra work and then record
> it as a new item of data, which you don't actually need, but that's just hot
> Git works.

What extra work? If you just want to commit everything you've changed, you 
say "git commit -all" or some such, and away you go. If you want to take my 
changes and update your repository, you say "git pull darren", and when 
you're ready to incorporate my changes into your development, you say "git 
merge darren".  It's two steps because you don't want to tie "get Darren's 
changes" to "make sure Darren's changes are all compatible with mine."

>>> So doing things the hard way is brilliant?
>>
>> Building an entire type theory to discuss isomorphic idempotent change
>> sets is the easy way?
>
> After you've built it, yes. The theory is hard, but it makes using the tool
> easy.

Honestly, I'm not sure I see any advantage of Darcs over git, other than 
possibly repository size. I imagine once you get enough change sets in a 
repository (think 10 years of Linux development), it could get really slow 
to check out a particular file.

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

Post a reply to this message