Miles Gould writes: > Hence, a darcs user looks at git and says "Git doesn't support > dependency-aware cherry-picking, how useless; why should I care > about easy branching?", and a git user looks at darcs and says > "Darcs doesn't support easy branching, how useless; why should I > care about cherry-picking?". But to say that "git doesn't support > real cherry-picking"
"Dependency-aware" isn't really the problem. I often use ephemeral branches for things like collecting small bug-fixes (eg, output formatting). Almost by definition these can't involve dependencies. The point of using a new branch is to ensure that these changes are recorded in the context where they were created (which queues/quilts can't do), and without either creating merge conflicts or cluttering up semantic changes with irrelevancy. But Darcs does that automatically, and you can cherrypick those patches into as many branches as you like without creating merge issues for later. So when I write "real cherry-picking" I mean tracking that fact that a patch was applied to avoid spurious conflicts when merging branches, not the issue of pulling dependencies with it. I think that's what most people mean by "real" cherry-picking, but YMMV. Since as you point out neither git nor darcs can automatically provide "precise dependencies" (whatever that actually means), the practical issue with cherry-picking is not tracking dependency in general, but tracking dependency on the cherry-picked patch itself. Git doesn't do that at all, unless you put the patch (and any dependencies you want) on a separate branch. > I think of it as optimistic versus pessimistic dependency-tracking: I like that distinction. It's great for explaining to patch-oriented thinking, which is the way most developers think. (The alternative is revision-oriented thinking, in which instead of *inventing* patches and *adding* them to the project history, you *discover* revisions, and *record* their position in the history. Revision-oriented thinking is much more adapted to the way git actually works, but it's unnatural.) BTW, as you guessed, "darcs commit --ask-deps" allows you to add patch dependencies to record semantic dependencies that are not signaled by textual conflicts. > [BTW: the "retroactively branch + cherry-pick" thing works fine in git > too, I'm not sure what you mean by "retroactively branch" in git. But for the interpretations I've come up with, I don't think it "works fine". In all of those it will result in spurious conflicts when merging the branches, which in not so extreme cases makes them unmergable. > All of those ideas sound extremely similar to git's unpacked repo > format. Only at a very high level of abstraction where everything is a blob. For example, Git's packed repo format uses delta compression, but you can't directly name and extract those deltas. You need to extract two revisions and diff them. On the contrary, in Darcs you will be able to extract a patch by name. But you can't (in general) extract a revision by name; you need to extract a base revision, and apply patches to it. BTW, "unpacked repo format" is a red herring. It's not semantically different from the packed repo. It's just that the packed format is, well, packed. That just means that you can't inspect the structure without git. _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
