On 4/23/2011 3:47, Orchid XP v8 wrote:
> I will admit, a GUI is probably a superior interface for doing this. (And
> I'm not aware of anyone having built a GUI for Darcs.)

There's a couple of standard git guis that come with git. One for really 
sophisticated exploration of the history and one for manipulation of the 
repository and working directory.

>> Which means you can't (for example) stop in the middle when you realize

> True enough. It would be nice if you could make Darcs remember which changes
> you selected last time around. (Then again, some of those changes might no
> longer exist next time you run Darcs...)

Git also does some various funky things. Like if you're doing merges and you 
get a conflict, it leaves extra information in the "index" part to keep 
track of which merge conflicts you've fixed and which you haven't. The 
"bisect" routine (which Darcs has as well) uses that area to track stuff. Etc.

Of course, in git they'll still exist, because it gets copied into the 
repository when you say "remember this change", not when you say "commit".

> 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.)

> 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.

> It's more the conceptual annoyance of having to record every merge operation
> as a new version of the entire repo, even if you only changed one line. That
> seems really clumsy to me.

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.

>> Honestly, I'm not sure I see any advantage of Darcs over git.
>
> Likewise, but inverted.

Well, here's the advantages of git, so far:

Git can keep multiple branches in one repository, which makes it easier to 
move changes around, look at history, try out new combinations of changes, etc.

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 didn't see that in Darcs, but 
I didn't look very close.)

git keeps a history that can tell me what changes rely on other changes 
semantically, not just syntactically. (I.e., the thing Darcs tries to do 
with the retoken command, except that really only works for one specific 
type of semantic change and still only works syntactically.)

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.

git has all kinds of sweet tools to manipulate the repository in ways Darcs 
can't very easily. (Basically, you'd have to tell Darcs to make a bunch of 
snapshots, then fiddle with the snapshots the same way git would fiddle with 
the repository itself.)

> 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.

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.

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

Post a reply to this message