On 4/29/2011 9:55, Orchid XP v8 wrote:
> yet Git assumes that it does.

Yep. It's a question of whether you're being conservative or not, is all.

> Fundamentally, I expect working out which changes truly depend on each other
> is probably undecidable.

I don't think it's undecidable. I think it merely depends on what your specs 
are.

Indeed, if I take a file that prints nothing and make it print "Hello", and 
you take a file that prints nothing and make it print "Goodbye", then it's 
obviously impossible to figure out in the merge which should come first and 
which should come second, or if either at all is right.

> Apparently both models do work in practise, since there are people using
> them. Personally, I much prefer the way Darcs does it.

I can see the appeal of both. I wasn't really pushing for git as being 
better. My original post was "hey, I found a good way to understand it."

> I imagine Darcs will say "error, these changes conflict, please fix it". And
> other words, "I can't figure out what to do; you decide".

But then how do you resolve it, such that I get the same resolution?

>> Resolving this in git is very straightforward. You can just pick one
>> that's right and say "Henceforth, that's the answer". Or you can just
>> grab all the changes and basically never merge them back together again
>> (say, if you have two distros in the same repository).
>
> That sounds in principle like the same thing that Darcs does.

I don't think Darcs lets me merge your patches back in and easily work on 
one set or the other, right? Each repository really only holds one 
authoritative version of the patches, right?  I.e., there's exactly one 
"pristine" that you compare against?

>> Also, what happens if I rename a file from XXX to YYY and you rename it
>> from XXX to ZZZ? Do I wind up with both YYY and ZZZ in my repository?
>
> Same again, I would imagine.

Yeah, OK.

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

Post a reply to this message