[forwarded from earlier reply to just James, kind of wish there was a “oops-I-forgot-to-reply-all” forgiving UI in my mailer]
Thanks for the thoughts on this, James On 10 September 2012 11:36, James Sleeman <ja...@gogo.co.nz> wrote: > Ideally from my horribly uneducated point of view, would be the (fanciful) > ability for there to be a "stand in" dependency patch, a special case of a > conflict resolution patch, which darcs sees as a substitute for some set of > patches we don't have but are depended upon by something we want. > > Example, "Repo D" contains Patch 1 and Patch 2 which depends on it. > I want to pull Patch 2 into "Repo 2", but not Patch 1. > What I'd really like to be able to do is say "darcs pull in Patch 2, > ignore the dependancy on Patch 1, and present any problems you have in > doing so as a conflict" ( something like: darcs pull -p"Patch 2" > --manually-resolve-dependancy=**"Patch 1" [sourcerepo] ) > Then I'd resolve the conflict and record that patch as a "stand in" for > Patch 1, darcs would of course have to know that it's recording the > stand-in (something like: darcs record > --stand-in-for-missing-**dependancy="Patch > 1") > If at any time I brought in Patch 1, then it would "mask out" the stand in > patch > So do I understand correctly that what you're aiming at in this hypothetical scenario is “push Patch 2 over even if it depends on Patch 1 [and do whatever it takes to make it possible]”? Do you actually want something conflict based, or would you for example, prefer an alternative based on “breaking up” Patch 1 so that we can ship over only the bits of it that matter? As you've described the problem, my current reflex would be to reach for darcs rebase indeed, but am I missing something in wanting to do so? So one random aside: if we look at version control systems as being relatively pessimistic vs optimistic about dependencies (Git more pessimistic than Darcs), if I understand both you and Gracjan correctly, we have here two cases where you were teased by Darcs' optimism but in a way surprised/disappointed by the remaining bits of pessimism (either because the dependencies are too strong in practice, or the UI for presenting why things depend is still not good enough, etc…). It's interesting to see people seeming to want a bit of optimism in their lives. (I don't mean to oversimplify though) Thanks, Eric PS. I'm still looking at something related to the performance issue you pointed out earlier, specifically the fact that unrelated changes wind you in your pending patch). It's resulted in the sadly incomplete http://darcs.net/Internals/PendingPatch (which is oriented towards darcs developers), as well as a rough plan for addressing the problem, but it would take me some time to work out the actual implementation, and I certainly wouldn't mind somebody else picking up the ball… -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
