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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Martin Langhoff wrote:

>On 4/2/06, Sam Vilain <sam@xxxxxxxxxx> 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.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]