Version control systems
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Sun Aug 17 22:21:47 EDT 2008
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).
> 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
>>> and darcs (some libraries). Does anyone know how git handles
>>> nested repos
>>> even natively?
>> You can explicitly tell Git about nested Git repos using
>> This essentially associates a particular version of each subrepo with
>> every version of the repo that contains them, so e.g. checking out
>> from 2 weeks ago could check out the libraries from the same point in
> 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
>>> 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
> have changed, so the build won't think it is up-to-date any more and
> 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
> 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
> Hopefully a git person will correct me if I've got something wrong!
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users