On 4/23/2011 12:24, Orchid XP v8 wrote:
> In other words, Git is *guessing* which changes depend on each other
> semantically from which changes were written at the same point in time in
> the same repo.

No. git is merely recording what changes from your repository you had 
already applied to your working directory at the time you made the change. 
It's not guessing that it's semantically meaningful. It's recording it in 
case it is.

> I could change thing X, and then change thing Y which has nothing to do with
> thing X, and still Git will assume a relationship exists there. Darcs, on
> the other hand, only concerns itself with *real* dependencies.

But if you change Y that depends on me *not* having changed X, that's a real 
dependency that darcs does *not* track.

> It's also true that Git can't guarantee that the code in any
> particular commit object is runnable either.

But *I* can guarantee that code in any particular commit object is runnable. 
I can test it. I can't do that with darcs, because fetching new stuff might 
retroactively change whether something works in a way that isn't recorded in 
the repository.

> For every true dependency, there will be a bazillion spurious ones. So it's
> a case of "Which is worse? Missing some real dependencies, or recording
> millions of fake ones?" Given that the former is much simpler conceptually,
> I'll go with that thanks.

I think your "fake dependency" aversion is kind of silly, since nobody 
really records fake dependencies.

>> If I have a repository and I merge in a bunch of your changes and apply
>> them, then I merge in a bunch of changes from Jim, I could very well get
>> tons of conflicts if Jim didn't apply your changes when he started working.
>
> Is this not the case for every known distributed version control system?

Yes. But git lets me resolve the issue, while darcs makes it a very manual 
process for me to figure out *why* Jim's changes conflict.  If I go to merge 
Jim's changes, darcs gives me no help. Git tells me what version Jim's 
changes are *supposed* to merge cleanly into.

>> It seems fragile to me to have a working directory and a repository
>> where I can incorporate changes into the repository that I cannot get
>> into the working directory to work on.
>
> Why can't you get them into the working directory?

Because that messes up my working directory in a way I can't recover from.

> It pulls down the *pristine* copy, which contains only recorded changes.
> [And is compressed.] If you're silly enough to delete that, then you just
> broke your repo. (I'm not sure whether the repair command can fix this... I
> believe so, but I've never tried it. It probably won't be fast though.)

OK, so darcs doesn't record only the changes, but the changes and then the 
result of applying all those changes, *and* you have a working directory. 
That makes a bit more sense I guess.

>> Like the bisecting command, just as an example. Or the stash command.
> Without looking those up, I don't know what they do.

Ways of saving your changes temporarily in a different part of the repository.

>> Or commiting things in phases.
>
> You mean like if you go to record something and realise you want to tweak it
> first?

Yes. Resolving merges a bit at a time, compiling and testing in between, 
rather than having the "record" and "commit" be the same action.

>There's no really fundamental reason why Darcs
> couldn't keep a history of what's happened to your repo though.

I agree. It just doesn't.

 > (And keep it
> local to that repo, not part of the shared change history.)

No, that doesn't work, because you still want that history when you clone 
the repository or it's useless in the bigger picture.  Especially when 
cloning the repository is how you make a temporary branch.

>> BTW, if you ever want to play, there's a script for git that will import
>> the changes from and export to a Darcs repository.
>
> Given the radically different ways in which the two systems work, I imagine
> the history gets pretty mangled in the conversion - no matter which system
> you believe is the "correct" one.

The git import function works by running a script to "get the next version" 
and then checking it in, over and over, until it's all checked in. If you 
can write a script that says "make a file that holds the commit message, and 
a command line to fetch the next version", then you have enough for git.

Of course, darcs doesn't really have a "next version" concept, so that could 
be problematic.

> Is this the same Yoda who lived in a universe where you can literally make
> inanimate objects physically move just by *believing* that you can?

You have a point.

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

Post a reply to this message