On 4/21/2011 13:28, Orchid XP v8 wrote:
> Right. Every time you edit a file, it's actually a new file.

In the repository, yes. Obviously, git knows that there's a file in your 
repository with the same path and name as a file in my repository but 
different contents.

>> When I want to put your changes into *my* version of the files, I have
>> to merge it, just like Darcs.
>
> 1. Having a copy of someone else's changes is useless unless I can
> incorporate them into the latest version of the files.

Which latest versions? Oh, right, Darcs only has one latest version, and if 
you don't want to apply changes from someone, you can't fetch them either.

> This is the
> equivilent of three people taking copies of a file, editing it, and emailing
> me back three modified files. I don't want three files, I want *one* which
> has all the edits in it.

That's the merge step. Three people send you three copies. When you're 
ready, you say "apply those changes to my copy."  I'm not sure where your 
confusion is. In Darcs, that's one step it seems - I can't get changes from 
you *without* applying them to the work I'm doing. In git, it's two steps, 
because maybe you're in the middle of something and you don't want to merge 
in my changes until the stuff you're working on actually works and passes 
tests and stuff.

> 2. If I do "darcs pull", all new history is copied to my repo, and the
> working copy is updated to reflect these changes. [Assuming there are no
> conflicts of course.] That's it. That's all you have to do.

So if you have something like Linux, where there's a new release every few 
months, you need a complete repository for every release. And if I fix a bug 
in an old release and you want to incorporate that bug fix into newer 
releases, what do you do?

> With Git, you have to do some crazy thing with comparing my working copy to
> the most recent common ancestor of my branch and the branch I'm pulling,
> creating diffs for that, comparing the most recent common ancestor to the
> snapshot I just pulled, creating a diff for that, combining the two diffs,
> and then applying that to the most recent common ancestor.

git does all that. Complaining about that is like me complaining "To check 
out a working copy from Darcs, I have to do some crazy thing about 
topological sorts on patches, then applying them to empty files in the right 
order, it's nuts!"

 > You then have to
> *create a new commit object* representing this new combined state.

Yes.

> Every time you try to combine two states of the repo, it creates a new
> commit object representing the merge. Darcs, by contrast, lets me trivially
> apply any combination of changes I want. I can even create files with
> combinations of changes that have never existed before if I like.

You can do that in git too. You have to create a commit if you want to store 
it in the repository, tho.

> I guess the thing that really flips my lid is that not only does Git require
> you to construct a useless merge commit every time you want to do something
> as trivial as put two changes together,

Commits are trivially inexpensive in git. They represent the state of some 
particular repository at some particular time. It's how you store stuff.

Say you have 25 changes in your Darcs repository, and you want a version 
that applies every change except #23. What do you put in the repository to 
represent that?

> but if you want to put new stuff
> into a repo, you have to somehow get the merge up to date first.

No. You really aren't listening to what I'm saying, so I'm not sure why I'm 
bothering.

You only have to do that step *IF* nobody is going to look for merge 
conflicts. I.e., *you* have to do that step *only* in the case that *you* 
want to change *my* repository without *me* being there. Which is something 
Darcs can't do at all.

> It also irritates me that Git insists that even unrelated changes must have
> a linear time ordering.

No they don't. Indeed, if unrelated changes had to have a linear time 
ordering, you wouldn't get merge conflicts at all, would you? Then you 
wouldn't be complaining about git having merge commits.

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

Post a reply to this message