From: Sam Vilain Date: Mon, 03 Apr 2006 02:09:42 GMT Subject: Re: Multi-headed branches (hydra? :)) for basic patch calculus Message-ID: <443083E6.9090204@vilain.net> In-Reply-To: <46a038f90604021815g453c57c9pf95a0f70a62f2fbc@mail.gmail.com> Martin Langhoff wrote: >On 4/2/06, Sam Vilain wrote: > > >>If the plumbing or a porcelain could be smart enough to automatically >>create hydra when patches are not dependent, then many of the benefits >>of patch calculus might come for free, without having to create these >>complicated sounding entities manually. >> >> > >I'm not too excited about the benefits of patch calculus -- it seems >to break many general usage scenarios(*) and I haven't seen many >examples of those benefits that aren't a bit contrived. > >* - For instance: the common practice of having a patch series where >you create a new function and later add calls to it breaks quite >seriously under patch calculus. > > Perhaps. But forget the darcs implementation for a moment. When you make a commit, you're labelling it with the previous dependent commit for this commit to apply. So, git-commit-hydra would do this calculation based on the files changed. git-commit would assume the prior commit. You still have both options available. >Are there common usage scenarios where patch calculus helps more than >it hurts? Preferrably without involving manual recording of >dependencies or full language parsers that guess them. > > I am in the process of converting a live repository as if it had been committed to in this manner. I'll post results shortly. Sam.