> Wow. Advice: Don't talk to anyone about how git works, since even if you
> think you've figured it out, you haven't.
>
>> Obviously this model cannot possibly work, so there must be something I'm
>> misunderstanding about how Git works.
>
> Ah, thank you.

Like I said, the way Git appears to work is utterly hopeless, so I must 
have got something wrong somewhere.

> So when you send your change to the maintainers, you're sending them new
> files. There are no merge conflicts, because there is no merge.

Right. Every time you edit a file, it's actually a new file.

> So sending your changes to someone else doesn't cause merge conflicts,
> and there's no need to back them out.

OK.

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

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.

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. You then have to *create a new commit object* 
representing this new combined state.

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.

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, but if you want to 
put new stuff into a repo, you have to somehow get the merge up to date 
first. That sounds increadibly fragile.

It also irritates me that Git insists that even unrelated changes must 
have a linear time ordering. Still, it's not like I actually have to 
*use* Git, so it doesn't really matter if I don't like it...

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

Post a reply to this message