![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 29/04/2011 05:16 PM, Darren New wrote:
> Indeed, that's my main complaint with the whole concept: the idea that
> simply because two patches are in different files doesn't mean they're
> unrelated. If I implement foo() in file abc.c and call foo() in file
> def.c, those are not two unrelated patches.
And my complaint about Git is that just because change X happened after
change Y does not necessarily mean that change X depends on change Y in
any way, yet Git assumes that it does.
Fundamentally, I expect working out which changes truly depend on each
other is probably undecidable. [And that's before we even get into the
fact that the only way for this to work properly is to implement a
seperate detection engine for every programming language you ever want
to version control.]
Apparently both models do work in practise, since there are people using
them. Personally, I much prefer the way Darcs does it.
> We both record our changes.
>
> We attempt to merge our repositories.
>
> Can you try this on a blank repository on your machine and tell me what
> happens?
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".
> 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.
> 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.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 29/04/2011 05:18 PM, Darren New wrote:
> BTW, the problem here is that those patches are *not* related. Each
> branch down the side is a separate Darcs repository. So the first guy
> takes A, makes it a B, then patches it back to A. In parallel, in *your*
> repository, you independently take A and make it into B. Now everyone
> copy all the patches from everyone else. Do I wind up with A or B? I'm
> not sure there's an answer there that makes sense from a technical
> perspective.
I haven't tried it personally, but as I understand it, Darcs says "there
is a conflict here; please decide what you want me to do".
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 4/29/2011 10:18, Darren New wrote:
> 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.
Or, to be fair, more appropriately, git doesn't imply that just because
change A followed change B that change B depends on change A. Reading
dependencies into the order of commits is reading in something that isn't there.
Git is storing a series of snapshots. Each commit contains a complete record
of everything that was in your working directory when you committed it
(sorta, using Darcs terms). Each commit points to the version that was in
your working directory that you changed in order to get the new version. As
I said, git doesn't store changes. It says "he started with X, then he had
with Y," with no real implication that Y somehow depends on X.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Wed, 20 Apr 2011 16:49:57 +0100 in povray.off-topic, Invisible wrote:
> The problem Git seems to have is that it uses heads to keep track of
> things. Delete the head and the corresponding commit drops off the face
> of the Earth.
Actually, there are usually many ways to retrieve a lost head.
.git/logs/ directory is the most prominent tool or that.
The terminal's history buffer is another. Usually the very
commands that drop the current head will print its name.
--
Joel Yliluoma - http://iki.fi/bisqwit/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 5/27/2011 1:31, Joel Yliluoma wrote:
> On Wed, 20 Apr 2011 16:49:57 +0100 in povray.off-topic, Invisible wrote:
>> The problem Git seems to have is that it uses heads to keep track of
>> things. Delete the head and the corresponding commit drops off the face
>> of the Earth.
>
> Actually, there are usually many ways to retrieve a lost head.
> .git/logs/ directory is the most prominent tool or that.
Actually, there are "relog" or "rehead" files or something like that, which
are basically text files listing each head and the corresponding SHA1 as a
log file each time you move a head.
Also, doing the equivalent of a chkdsk will give you back any SHA1's that
don't have anything else pointing to them.
Both intentionally stick around for quite some time (several weeks by default).
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |