|
 |
On 4/23/2011 10:38, Orchid XP v8 wrote:
>> But if they don't conflict, then that's one step. (Well, one step for
>> each of the 200 changes, just like in Darcs.)
>
> Except that you have to record the order you did it in, even though it
> doesn't actually matter.
You *can* do all 200 at once, if you want. It's just a mess to specify.
>> No, it doesn't really work like that. Like I said, of the Linux repo,
>> there's 240,000 commits, of which 15,000 are actually merges. Git has a
>> lot of ways of editing the history to make it look simpler, which is
>> where all the perceived complexity of git lies.
>
> I might suggest that if you *need* the ability to edit history to make it
> look simpler, you're doing it wrong.
One is editing history only to back out changes or rearrange commits. Once
it's in a repository anyone else can see, you can't edit it safely any more.
Just like Darcs.
> Except that with Darcs, you don't need to record the fact that a branch ever
> even existed. You just record what was done with the actual file contents.
I would classify that as a problem, not a benefit. I'd like to know which
patches were developed independently, when they were incorporated into the
current code, etc.
>> Well, here's the advantages of git, so far:
>>
>> Git can keep multiple branches in one repository
>
> I don't know how that works, but if you mean you can have multiple working
> copies, then yes, I guess that could be quite useful.
No. It's exactly like having multiple repositories in one directory.
Branching in git is cloning the repository in Darcs. Merging in git is a
pull in Darcs.
>> Git keeps track of where changes came from and when, so if I pull in a
>> 2-month-old changeset and it breaks something, I can figure out when I
>> pulled it in vs when you wrote the change.
>
> I'm not sure I see why you would need that information, but OK, Darcs can't
> tell you about that.
Because if you created a patch six months ago and I only applied it last
week, it would be good to know that when things start breaking, it *might*
be because of a change that I only saw a week ago, and I might have to go
back as far as six months worth of changes to understand the problem.
You really don't see the benefit of knowing the difference between "when I
wrote the code" and "when I gave you the code"? It's the same reason you
put version numbers on executable files you distribute - so you know what
you're running when.
>> git keeps a history that can tell me what changes rely on other changes
>> semantically, not just syntactically.
>
> How?
Exactly that "linear" order you're complaining about. The DAG of commits
tells you which changes were written with one version in mind but without
other changes in mind.
If I change on April 1 the semantics of function XYZ, then I write code on
April 3 depending on the new semantics, and you on April 5 write code
depending on the old semantics, you now have a dependency from your code to
the April 1 code that isn't recorded anywhere in Darcs. It's recorded in
git, tho.
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.
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.
>> git doesn't have to spend tens of hours applying 240,000 change sets to
>> the repository in order to give me the latest version of the files.
>
> Neither does Darcs.
Sure it does. Delete your working directory.
When you clone git, it pulls down the repository, then creates the working
directory from that. When you clone darcs, it sounds like it pulls down both
the repository and the working copy (which would seem problematic if the
working copy had changes to it that weren't recorded, yes?).
>> git has all kinds of sweet tools to manipulate the repository in ways
>> Darcs can't very easily.
>
> Ways such as what?
Like the bisecting command, just as an example. Or the stash command. Or
commiting things in phases. Or efficiently giving me a copy of the files as
they existed at a specific point in time. (Indeed, since Darcs doesn't
actually record what order you pulled changes in, it seems Darcs can't
really even do that inefficiently.)
>>> Still, until GHC moves from Darcs to Git, I won't have to actually
>>> care, so I guess it doesn't really matter.
>>
>> Not unless you wind up working on a project that uses git.
>
> That isn't going to happen.
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.
http://vmiklos.hu/project/darcs-fast-export/git-darcs
Just from reading the comments, it looks like it stores the Darcs repository
as one branch of the git repository, treating it like a remote repository.
> 1. I will never wind up "working" on anything that's version-controlled. I
> am apparently doomed to spend the rest of my /working/ life rebooting
> people's PCs because Word crashed, rather than doing interesting coding tasks.
<Yoda> And that is why you fail. </Yoda>
> 2. If we're talking about hobby projects, obviously I'm going to pick one
> that uses my preferred tools.
Sure.
> It's not that I don't understand the difference between Git and Darcs. It's
> that I can't begin to comprehend how what Git does can work. It just seems
> such an obviously stupid way to approach the problem.
It seems like a tremendously elegant system to me, like the relational model
for version control. You have a big pile of snapshots, one for each
committed set of changes. All differences are calculated from the snapshots
as needed.
Darcs too is fairly elegant. If they had a more sophisticated way of
handling groupings of changes besides "clone the entire repository and then
make irreversable changes to it" it would be even better.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
