On 12/01/2011 22:22, Iavor Diatchki wrote:
Hello,
On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy <r...@cse.unsw.edu.au
<mailto:r...@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.
-Iavor
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.
I spent quite some time yesterday playing with submodules to see if they
would work for GHC. I'm fairly sure there are no fundamental reasons
that we couldn't use them, but there are enough gotchas to put me off.
I wrote down what I discovered here:
http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Submodules
The workflow is quite involved - more steps than are required with
darcs-all (understandable, because we're storing more information).
However, git isn't particularly helpful if you make a mistake or forget
to do something. I forsee spending a lot of time digging myself and
Simon out of bizarre repository states.
I discovered that Google have this tool called "repo" which is their
darcs-all for the Android source tree. That might be worth looking at
as an alternative in the future:
https://sites.google.com/a/android.com/opensource/download/using-repo
If we go with git, I suggest we stick with sync-all for the time being
and think about either submodules or repo as possibilities for the future.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
