John Lato writes: > Besides, that's rather beside the point. git-rebase is cheap because it's > very common, and it needs to be cheap to be used widely in order to keep > histories clean. Which was my main point. Unless you're arguing that > because git-rebase is usually fast, git users just use it arbitrarily > without regard to a clean history?
Sorry about introducing the performance red herring here. What I want to argue is that rebase allowing you to mandate a linear history (a better characterization of what you really get from rebase) is insufficient to keep history clean in the sense of allowing easy cherry-picking: you also need a well-factored design. > > > 1. Every patch applied after a base patch depends on the base patch. > > > 2. A base patch doesn't depend on anything, but it conflicts anywhere > > > its dependents would conflict. > > > > I take it a base patch must be empty? Surely it would depend on the > > patch that adds the only file the base patch patches, for example? ;-) > > I highly doubt that situation would come up much in practice, I don't understand what you mean. Every file gets added at some point. This means that you can go all the way back to the beginning of the world unless the patch is empty. > and even if it does I think the correct approach would be to give > the user a choice between aborting, creating a null file, or > attempting to patch a different file. AFAICS only aborting would make sense in general (you can't apply a change-line or delete-line diff to a null file, you can't leave the file null and claim to have applied the diff, and darcs tracks renames so it should know which different file if there is one). > > > When trying to apply the base patch to the stable repo, the > > > base patch will conflict everywhere hotfix's dependencies are > > > unmet. To resolve the conflicts, we first undo hotfix, So by "undo" you mean obliterate the patch but leave the changes (including conflict markers) in place, for convenience of editing? > > > then apply hotfix' (the new patch). We don't actually touch What does "actually touch" mean? > > > the base patch when resolving conflicts, but after the > > > resolution, the base patch's dependents have changed, so now > > > it will only conflict where hotfix' would (since the original > > > hotfix is undone). > > > > I don't understand why this changes anything. The dependencies of > > hotfix are determined by the patches that establish the context it > > needs to be applied to. I don't see why anything would change for > > hotfix' if it contains the same changes are hotfix. > > hotfix' is a darcs merge patch, so it's hotfix+manual edits. The manual > edits make the difference :) Its dependencies would be hotfix, hotfix(-1) > (the inverse patch), and whatever else is between it and the base patch > that's necessary for context. IIUC, for these effects your "base patch" could be implemented as a Darcs tag. I see two problems with the theory you present though. One is that hotfix' is just going to be a new patch. The other is that AFAIK (see caveat below) there is a theorem of patch theory that says hotfix' can't depend on both hotfix and -hotfix, since hotfix + -hotfix = 0. And I still don't understand how you handle context that was established outside of the base patch and subsequent patches, unless the base patch is implemented as a tag (which guarantees that no such context exists). > This workflow would be enabled by the base patch implementation. What a > base patch provides to the user are two features: I don't want to be harsh, but I suspect this is based on an incomplete understanding of how patch theory works. I don't claim to understand patch theory myself, except that it seems clear that the only way to create a given patch that no dependency can "leapfrog" is for the given patch to be a tag, ie, a patch that depends on all "preceding" patches in the repo and thus defines a version. Your idea of a base patch that doesn't depend on anything doesn't seem consistent with the basic ideas of patch theory. It occurs to me that Ben's ideas may imply a sort of "tag algebra" to go with "patch algebra". _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
