RFC: migrating to git

Iavor Diatchki iavor.diatchki at gmail.com
Wed Jan 12 23:22:37 CET 2011


On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy <rl at cse.unsw.edu.au>wrote:

> On 12/01/2011, at 09:22, Simon Marlow wrote:
> > On 11/01/2011 23:11, Roman Leshchinskiy wrote:
> >>
> >> A quick look at the docs seems to indicate that we'd need to do
> >>
> >> git pull
> >> git submodule update
> >>
> >> which doesn't look like a win over darcs-all. Also, I completely fail to
> understand what git submodule update does. It doesn't seem to pull all
> patches from the master repo. The git submodule docs are even worse than the
> rest of the git docs which is rather discouraging.
> >
> > True, however the build system could automatically check whether you had
> missed this step, because it could check the hashes.
> That would be an improvement. How do you pull submodule patches which the
> main repo doesn't depend on, though? Out of curiousity, has anyone here used
> submodules for something similar to what we would need?

A "submodule" is basically a "pointer" to a particular state of a remote
repo.  So when you do "git pull" in GHC, you get changes to the code, and
also changes to this "pointer", but it won't automatically modify your local
version of the sub-module repo.  So at this point, if you started "git gui"
you'd see that there is a mismatch between your local copy of the sub-module
and the expected version.

When you issue the command "git submodule update", you are telling git to
advance the sub-module repo to the "expected version" (i.e., where the
pointer points to).  The reason this does not happen automatically is that
you might have also made changes to the submodule, so you might want to do
some merging there, instead of just pulling.

One thing to note is that if we were to set things up with sub-modules, then
every now and then we would have to advance the GHC's "expected pointer" for
various libraries to the latest (or a newer) version.  Of course, we could
have a script do this but, at least in theory, when someone makes a commit
which updates the version of a sub-module, they are asserting that they
things ought to work with the newer version of the sub-module.

PS: I've only used sub-module on what project at work.  At first I too was
quite confused about what was going on, but I've come to think that
submodules are a pretty reasonable way to deal with a situation which is
inherently complex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20110112/0c1c0f4b/attachment-0001.htm>

More information about the Glasgow-haskell-users mailing list