Version control systems

Sittampalam, Ganesh ganesh.sittampalam at credit-suisse.com
Mon Aug 11 08:34:22 EDT 2008


 

-----Original Message-----
From: Thomas Schilling [mailto:nominolo at googlemail.com] 
Sent: 11 August 2008 12:18
To: Sittampalam, Ganesh
Cc: Manuel Chakravarty; Don Stewart; Ian Lynagh; Simon Peyton-Jones; GHC
Users Mailing List
Subject: Re: Version control systems

Thomas Schilling wrote:

> On 11 Aug 2008, at 12:38, Sittampalam, Ganesh wrote:

>> Thomas Schilling wrote:
>>
>>> (I am also no longer convinced that Darcs'
>>> automatic patch dependency calculations are actually a good idea.  
>>> Just because two patches don't touch the same files, doesn't mean 
>>> they aren't semantically dependent.  Take for example 
>>> "monadification" patches, which are typically submitted split up for

>>> each file.
>>> A branch captures those dependencies just fine.)
>>
>> But the darcs approach to dependency is what underlies
cherry-picking, 
>> which many people consider the most worthwhile feature of darcs. In 
>> fact many people would like it to be possible to override even the 
>> dependencies that darcs *does* find to cherry-pick patch A without 
>> patch B that A depends on, at the expense of producing a conflict
that 
>> then has to be fixed up by hand.

> Cherry-picking just a single patch is simple in Git: "git cherry-pick
<commit-id>"[1].

I wasn't saying that Git doesn't support cherry-picking, just that you
would expect dependencies to restrict what you can and can't
cherry-pick; if you specify dependencies just in a linear fashion along
each branch (i.e. each patch depends on all those before it on that
branch) as I thought you were suggesting, then you enormously restrict
what cherry-picks are possible.

Ganesh

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================



More information about the Glasgow-haskell-users mailing list