 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/21/2011 13:28, Orchid XP v8 wrote:
> Right. Every time you edit a file, it's actually a new file.
In the repository, yes. Obviously, git knows that there's a file in your
repository with the same path and name as a file in my repository but
different contents.
>> 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.
Which latest versions? Oh, right, Darcs only has one latest version, and if
you don't want to apply changes from someone, you can't fetch them either.
> 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.
That's the merge step. Three people send you three copies. When you're
ready, you say "apply those changes to my copy." I'm not sure where your
confusion is. In Darcs, that's one step it seems - I can't get changes from
you *without* applying them to the work I'm doing. In git, it's two steps,
because maybe you're in the middle of something and you don't want to merge
in my changes until the stuff you're working on actually works and passes
tests and stuff.
> 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.
So if you have something like Linux, where there's a new release every few
months, you need a complete repository for every release. And if I fix a bug
in an old release and you want to incorporate that bug fix into newer
releases, what do you 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.
git does all that. Complaining about that is like me complaining "To check
out a working copy from Darcs, I have to do some crazy thing about
topological sorts on patches, then applying them to empty files in the right
order, it's nuts!"
> You then have to
> *create a new commit object* representing this new combined state.
Yes.
> 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.
You can do that in git too. You have to create a commit if you want to store
it in the repository, tho.
> 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,
Commits are trivially inexpensive in git. They represent the state of some
particular repository at some particular time. It's how you store stuff.
Say you have 25 changes in your Darcs repository, and you want a version
that applies every change except #23. What do you put in the repository to
represent that?
> but if you want to put new stuff
> into a repo, you have to somehow get the merge up to date first.
No. You really aren't listening to what I'm saying, so I'm not sure why I'm
bothering.
You only have to do that step *IF* nobody is going to look for merge
conflicts. I.e., *you* have to do that step *only* in the case that *you*
want to change *my* repository without *me* being there. Which is something
Darcs can't do at all.
> It also irritates me that Git insists that even unrelated changes must have
> a linear time ordering.
No they don't. Indeed, if unrelated changes had to have a linear time
ordering, you wouldn't get merge conflicts at all, would you? Then you
wouldn't be complaining about git having merge commits.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/21/2011 14:46, Darren New wrote:
>> So Git has a GUI tool that lets you do what Darcs does natively?
>
> It's native to git too.
Well, actually, the thing is, git has a bunch of layers. There's the layer
to just put a file into the staging index, a command to create a commit from
the staging index, a command to point a particular name at a particular
commit object, etc.
Everything beyond that, including deciding what hunks get included in those
files and so on, is at the next layer up. In exactly the same way that
Darcs runs on top of the file system.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/21/2011 13:28, Orchid XP v8 wrote:
> 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.
OK, so say I have a Darcs repository and I'm working on my program. I have
some changes in my working directory, when I come across a bug. I ask you
about it, and you say "that's already fixed." Can I pull just that one
change into my repository?
What if I'm working on version 1 of the program, and you made a fix in
version 2? How do I handle that?
Indeed, how do I get out a version of the working directory excluding just
one particular patch back in time, in order to see (for example) if that
patch was the cause of a bug? I didn't see that in the Darcs manual. All I
saw was deleting changes from the repository.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/21/2011 13:07, Orchid XP v8 wrote:
>> Well, git *does* store stuff in files, so technically you could copy the
>> files. But by "copy files" I mean "use git to copy the new files." As
>> in, "you don't have to run any diffs or patches or anything".
>
> Oh, I see.
Actually, you can store a repository on an http server and give everyone
read access to the repository, and everyone can update from there. So, yeah,
it basically *can* be done by copying the right files from one place to another.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/21/2011 13:28, Orchid XP v8 wrote:
> 1. Having a copy of someone else's changes is useless unless I can
> incorporate them into the latest version of the files.
Also, does Darcs record when you applied various patches?
So if, for example, I'm working, and everything's good, and I take some
patches from you, then work some more, then take some patches from Sam, then
work some more, then run my test and it fails, can I figure out that it was
Sam's patches, even if he created those patches before I even cloned the
repository in the first place?
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/21/2011 13:28, Orchid XP v8 wrote:
> Every time you try to combine two states of the repo, it creates a new
> commit object representing the merge.
Just to be clear, adding your changes to my repository is just adding a
commit. A commit is like a Darcs patch. One update of the repository is one
commit.
There's a "merge commit" which is nothing but a commit saying "this is what
it looks like after you merge two commits."
That said, the Linux repository going back 234 tagged versions (back to
2.6.11, which isn't all that far back) has 244,000 commits, of which only
15,000 are merges. So people tend to make 10 or more changes on each branch
before they merge it into the repository.
I'm not sure I'd want to check out something from Darcs that has a quarter
million patches in it and wait for Darcs to apply them all one by one. How
well does it handle that?
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/04/2011 12:39 AM, Darren New wrote:
> On 4/21/2011 13:07, Orchid XP v8 wrote:
>>> Well, git *does* store stuff in files, so technically you could copy the
>>> files. But by "copy files" I mean "use git to copy the new files." As
>>> in, "you don't have to run any diffs or patches or anything".
>>
>> Oh, I see.
>
> Actually, you can store a repository on an http server and give everyone
> read access to the repository, and everyone can update from there. So,
> yeah, it basically *can* be done by copying the right files from one
> place to another.
I've done this with Darcs. Unfortunately, to update the repo, you
basically delete it off the server and copy the current version over
there - which is tedious. (By default, the server would also have a
working copy - which is pointless. Fortunately, if you delete that bit,
it still works.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I much prefer the way Darcs does it (i.e., prompt you for which
>> changes you want to include in this particular commit).
>
> I prefer the GUI, actually. Much easier to pick out various commits to
> commit.
I will admit, a GUI is probably a superior interface for doing this.
(And I'm not aware of anyone having built a GUI for Darcs.)
>>>> not sure what you mean by "Darcs needs you to do that all in one step".
>>>
>>> I mean that gathering up the changes and committing them sounds like a
>>> single step in Darcs.
>>
>> A single interactive step, yes.
>
> Which means you can't (for example) stop in the middle when you realize
> you forgot to make one of the 30 changes you want to commit to fix
> something in particular. You have to start over.
True enough. It would be nice if you could make Darcs remember which
changes you selected last time around. (Then again, some of those
changes might no longer exist next time you run Darcs...)
>> Except that usually 200 people will be editing 200 different parts of the
>> repository.
>
> And if that's the case in git, then you have no trouble merging things
> when and as you want them.
You still have to manually make Git combine all 200 changes into one
version, and then commit that. It just seems like an undless cycle of
merges trying to keep everything straight, generating an ever more
tangled history behind it.
>> to do lots of extra work and then record
>> it as a new item of data, which you don't actually need, but that's
>> just hot
>> Git works.
>
> What extra work? If you just want to commit everything you've changed,
> you say "git commit -all" or some such, and away you go. If you want to
> take my changes and update your repository, you say "git pull darren",
> and when you're ready to incorporate my changes into your development,
> you say "git merge darren". It's two steps because you don't want to tie
> "get Darren's changes" to "make sure Darren's changes are all compatible
> with mine."
It's more the conceptual annoyance of having to record every merge
operation as a new version of the entire repo, even if you only changed
one line. That seems really clumsy to me.
> Honestly, I'm not sure I see any advantage of Darcs over git.
Likewise, but inverted.
Still, until GHC moves from Darcs to Git, I won't have to actually care,
so I guess it doesn't really matter.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/04/2011 12:31 AM, Darren New wrote:
> OK, so say I have a Darcs repository and I'm working on my program. I
> have some changes in my working directory, when I come across a bug. I
> ask you about it, and you say "that's already fixed." Can I pull just
> that one change into my repository?
Obviously yes.
> What if I'm working on version 1 of the program, and you made a fix in
> version 2? How do I handle that?
Depends which way I set it up. If each version of the program is just a
tag, then see the above. If each version is a seperate repo, you just
need to pull from the v2 repo. (How much conflict you'll have to deal
with is another matter - but that's the fun of backporting, eh?)
> Indeed, how do I get out a version of the working directory excluding
> just one particular patch back in time, in order to see (for example) if
> that patch was the cause of a bug?
You say to Darcs "please revert patch #34823". If that doesn't fix your
problem, you say to Darcs "please revert all unrecorded changes" (since
the inverse change you just asked for hasn't been recorded yet). If that
*does* fix your problem... well, you can just hit record, or you can
investigate further to see if you can keep the good parts of the
original patch without causeing problems, or whatever.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/04/2011 12:46 AM, Darren New wrote:
> On 4/21/2011 13:28, Orchid XP v8 wrote:
>> 1. Having a copy of someone else's changes is useless unless I can
>> incorporate them into the latest version of the files.
>
> Also, does Darcs record when you applied various patches?
Not to my knowledge, no. It records who created a patch and when, but
not when it was applied to any particular repo.
> So if, for example, I'm working, and everything's good, and I take some
> patches from you, then work some more, then take some patches from Sam,
> then work some more, then run my test and it fails, can I figure out
> that it was Sam's patches, even if he created those patches before I
> even cloned the repository in the first place?
In that case you're presumably going to revert patches until the problem
goes away. Maybe one patch broke something, maybe its an interaction of
several patches. You turn patches on and off until you figure out what's up.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
