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

Hint: Look up "darcs fetch". It fetches changes without applying them.

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

It's the fact that you have to commit the merged version of the file as 
a new version. Every time you merge in a new change, you have to commit 
a new version. It just seems clunky and unecessary.

> In Darcs, that's one step it seems - I can't get changes
> from you *without* applying them to the work I'm doing.

Not true. You can get changes without applying them. It's just that 
usually, you want to fetch changes to, you know, *use* them.

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

Then why fetch the changes at all? Why not wait until you're actually 
ready to apply them?

> So if you have something like Linux, where there's a new release every
> few months, you need a complete repository for every release.

Um... why?

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

Oh, I see. You mean if you actually have multiple versions of something 
being developed concurrently? Yeah, in that case you'd have to move the 
changeset from one branch to another and hope it works.

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

So if two people have the same repo, and they merge in change X and then 
later merge in change Y, and then the other guy merges in change Y first 
and later change X, they now apparently have conflicting histories. (And 
all because Git wants to pretend that everything happens in linear 
order.) How do you get out of that?

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

As I say, it just annoys me that you have to assign an arbitrary 
ordering to changes.

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

You ask Darcs to revert change #23.

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

This doesn't make any sense to me at all...

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

Post a reply to this message