John Lato writes: > A clear history is very useful for determining the context of > current work. Git users value this history quite highly, as > evidenced by the vast amount of time git users spend rebasing to > clean up history, developing best practices for maintaining a clean > history, etc.
git rebasing doesn't take that much time if you have a modular design and a clean history. If you lack either of those requisites, no VCS is going to be able to help you much. Even with the "dissolve to atomic changes" approach suggested by Ben Franksen, you will lose semantic dependencies among atomic changes that cause them to recorded together in a "coherent changeset" (Tom Lord's term). > 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? ;-) > 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, then apply hotfix' (the new patch). We > don't actually touch 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. >>>>> Ben Franksen <benjamin.frank...@bessy.de> writes: > I guess what I'd really want here is a new command, some version of > "darcs pull", that disregards patch identities (including patch > meta-data) and only considers atomic changes (hunks, etc). The idea > is to "dissolve" all the <unwanted dependencies>, and pull exactly > the set of atomic changes contained in them that are necessary to > apply the selected patch (<hotfix>). The result should then be > packed into a new patch. I think that this is much more in line with what is really needed to resolve spurious dependencies. However, if the changesets really are coherent, you'll end up with an incoherent version. The "new patch" mentioned here should be a new type of patch with "advisory conflicts" with the actual patches its atomic changes were drawn from. Or perhaps such conflicts could be resolved automatically. I suspect not: in some cases when you pull the "new patch", you would want conflicts automatically resolved by simply omitting the atomic change that conflicts. In other cases, however, you might want to pull in the original patches, or at least be informed that they exist. _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
