Version control systems

[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