Version control systems

[Manuel M T Chakravarty]

 From what you are saying, it seems that one "advantage" of git (in- 
place branch switching) is not going to be useful to GHC in any case  
(because we use nested repositories).

Manuel

Ian Lynagh:
> On Fri, Aug 15, 2008 at 01:01:08PM +0100, Max Bolingbroke wrote:
>> 2008/8/15 Isaac Dupree <isaacdupree at charter.net>:
>>> So let's figure out how it would work (I have doubts too!) So,  
>>> within the
>>> directory that's a git repo (ghc), we have some other repos, git  
>>> (testsuite)
>>> and darcs (some libraries).  Does anyone know how git handles  
>>> nested repos
>>> even natively?
>>
>> You can explicitly tell Git about nested Git repos using
>> http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html.
>> This essentially associates a particular version of each subrepo with
>> every version of the repo that contains them, so e.g. checking out  
>> GHC
>> from 2 weeks ago could check out the libraries from the same point in
>> time.
>
> We were talking about this last night on #ghc, and AIUI this doesn't
> play well with the in-tree branching style that is advocated, e.g. if
> you want to branch ghc and base then as you change between ghc  
> branch X
> and Y, git won't automatically change base between branches X' and Y'.
>
>>> Then, adding complexity, git branches are normally done by
>>> switching in-place.  So how does this interact with VCS like darcs  
>>> that
>>> doesn't have a concept of in-place switching of branches?
>
> The in-tree branching style also sounds like it won't work well with
> trees you are working in: If you have a tree built with branch X, and
> then you swap to branch Y for a minute and then back to branch X, then
> the timestamps on any source files that differ between the branches  
> will
> have changed, so the build won't think it is up-to-date any more and  
> you
> will get needless recompilation.
>
> Working only in the "master" branch, and using different repos for
> branches (i.e. doing what we do with darcs), is an option, although  
> git
> users seem to think it is a worse way to work; I'm not really clear on
> the main reasons why.
>
> One way that it is worse is that you will get a lot more "automatic
> merge" commits when you pull changes from the central repo into a repo
> in which you have local commits. I don't think that there is anything
> bad about these, as such; they're just noise in the history. (I'm not
> sure if it's possible to automatically rebase these away, or
> something?).
>
> Hopefully a git person will correct me if I've got something wrong!
>
>
> Thanks
> Ian
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users