>> You still have to manually make Git combine all 200 changes into one
>> version, and then commit that.
>
> But if they don't conflict, then that's one step. (Well, one step for
> each of the 200 changes, just like in Darcs.)

Except that you have to record the order you did it in, even though it 
doesn't actually matter.

>> It just seems like an undless cycle of merges
>> trying to keep everything straight, generating an ever more tangled
>> history behind it.
>
> No, it doesn't really work like that. Like I said, of the Linux repo,
> there's 240,000 commits, of which 15,000 are actually merges. Git has a
> lot of ways of editing the history to make it look simpler, which is
> where all the perceived complexity of git lies.

I might suggest that if you *need* the ability to edit history to make 
it look simpler, you're doing it wrong.

> Just so you know: There's merges, and there's commits. A commit is the
> same as what Darcs calls a changeset. A merge is when you have two
> different branches that you're putting into one repository.
>
> In git, a commit is a trivial thing. You say "git commit" just like in
> Darcs you say "darcs record." I do dozens of git commits a day just
> farting around with my own programs.
>
> In git, a merge is when you take two branches and apply the changes from
> one branch to the other branch. In Darcs, this would involve two
> separate repositories, one being updated from the other. It's about the
> same complexity as that.

Except that with Darcs, you don't need to record the fact that a branch 
ever even existed. You just record what was done with the actual file 
contents.

> Well, here's the advantages of git, so far:
>
> Git can keep multiple branches in one repository

I don't know how that works, but if you mean you can have multiple 
working copies, then yes, I guess that could be quite useful.

> Git keeps track of where changes came from and when, so if I pull in a
> 2-month-old changeset and it breaks something, I can figure out when I
> pulled it in vs when you wrote the change.

I'm not sure I see why you would need that information, but OK, Darcs 
can't tell you about that.

> git keeps a history that can tell me what changes rely on other changes
> semantically, not just syntactically.

How?

> git doesn't have to spend tens of hours applying 240,000 change sets to
> the repository in order to give me the latest version of the files.

Neither does Darcs.

> git has all kinds of sweet tools to manipulate the repository in ways
> Darcs can't very easily.

Ways such as what?

>> Still, until GHC moves from Darcs to Git, I won't have to actually
>> care, so I guess it doesn't really matter.
>
> Not unless you wind up working on a project that uses git.

That isn't going to happen.

1. I will never wind up "working" on anything that's version-controlled. 
I am apparently doomed to spend the rest of my /working/ life rebooting 
people's PCs because Word crashed, rather than doing interesting coding 
tasks.

2. If we're talking about hobby projects, obviously I'm going to pick 
one that uses my preferred tools.

> I think 90% of your confusion with git is you're trying to think about
> it like you think about Darcs, in terms of a series of changes, which is
> why I posted the original link in the first place.

It's not that I don't understand the difference between Git and Darcs. 
It's that I can't begin to comprehend how what Git does can work. It 
just seems such an obviously stupid way to approach the problem.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message