Re: Multi-headed branches (hydra? :)) for basic patch calculus

From: Sam Vilain <sam@vilain.net>
Date: Apr 3, 2006, 02:09 UTC
Message-ID: <443083E6.9090204@vilain.net>
In-Reply-To: <46a038f90604021815g453c57c9pf95a0f70a62f2fbc@mail.gmail.com>

Martin Langhoff wrote:

Show 19 quoted lines

>On 4/2/06, Sam Vilain <sam@vilain.net> 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.

Show 5 quoted lines

>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.