Hi,<br><div>Just as a point of information, the following rules can help avoid some of the gotchas:</div><div><br></div><div>- Treat submodules are read-only (i.e., don't make commits there). The reason for this is that a submodule is usually not on a branch, and so making a commit would result in a detached head.</div>
<div>- When you pull (or change branches) use "git submodule update" to move the submodules to their correct versions (yes, it's annoying that one has to do that).</div><div>- Changes to a sub-module should be done in a separate repo (not GHC's submodule). This is where you switch "hats" and become a "base" developer rather then a "GHC" developer for a bit, and use whatever workflow you normally use for development.</div>
<div> - Every now and then you update the sub-module "pointer" of your GHC branch to a newer versions of the sub-module. You do this by setting the sub-module to the desired version (e.g., by a pull from its repo), and then committing the change to the submodule version (perhaps with other GHC changes).<br>
</div><div><br></div><div>I agree with Simon's assessment that it is probably a good idea to start without submodules, at least until all developers are comfortable with the rest of git's model.</div><div><br></div>
<div>-Iavor</div><div><br></div><div><br></div><div><div><div class="gmail_quote">On Thu, Jan 13, 2011 at 12:49 AM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 12/01/2011 22:22, Iavor Diatchki wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hello,<br>
<br>
On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy <<a href="mailto:rl@cse.unsw.edu.au" target="_blank">rl@cse.unsw.edu.au</a><br></div><div><div></div><div class="h5">
<mailto:<a href="mailto:rl@cse.unsw.edu.au" target="_blank">rl@cse.unsw.edu.au</a>>> wrote:<br>
<br>
On 12/01/2011, at 09:22, Simon Marlow wrote:<br>
<br>
> On 11/01/2011 23:11, Roman Leshchinskiy wrote:<br>
>><br>
>> A quick look at the docs seems to indicate that we'd need to do<br>
>><br>
>> git pull<br>
>> git submodule update<br>
>><br>
>> which doesn't look like a win over darcs-all. Also, I completely<br>
fail to understand what git submodule update does. It doesn't seem<br>
to pull all patches from the master repo. The git submodule docs are<br>
even worse than the rest of the git docs which is rather discouraging.<br>
><br>
> True, however the build system could automatically check whether<br>
you had missed this step, because it could check the hashes.<br>
<br>
That would be an improvement. How do you pull submodule patches<br>
which the main repo doesn't depend on, though? Out of curiousity,<br>
has anyone here used submodules for something similar to what we<br>
would need?<br>
<br>
<br>
A "submodule" is basically a "pointer" to a particular state of a remote<br>
repo. So when you do "git pull" in GHC, you get changes to the code,<br>
and also changes to this "pointer", but it won't automatically modify<br>
your local version of the sub-module repo. So at this point, if you<br>
started "git gui" you'd see that there is a mismatch between your local<br>
copy of the sub-module and the expected version.<br>
<br>
When you issue the command "git submodule update", you are telling git<br>
to advance the sub-module repo to the "expected version" (i.e., where<br>
the pointer points to). The reason this does not happen automatically<br>
is that you might have also made changes to the submodule, so you might<br>
want to do some merging there, instead of just pulling.<br>
<br>
One thing to note is that if we were to set things up with sub-modules,<br>
then every now and then we would have to advance the GHC's "expected<br>
pointer" for various libraries to the latest (or a newer) version. Of<br>
course, we could have a script do this but, at least in theory, when<br>
someone makes a commit which updates the version of a sub-module, they<br>
are asserting that they things ought to work with the newer version of<br>
the sub-module.<br>
<br>
-Iavor<br>
PS: I've only used sub-module on what project at work. At first I too<br>
was quite confused about what was going on, but I've come to think that<br>
submodules are a pretty reasonable way to deal with a situation which is<br>
inherently complex.<br>
</div></div></blockquote>
<br>
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:<br>
<br>
<a href="http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Submodules" target="_blank">http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Submodules</a><br>
<br>
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.<br>
<br>
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:<br>
<br>
<a href="https://sites.google.com/a/android.com/opensource/download/using-repo" target="_blank">https://sites.google.com/a/android.com/opensource/download/using-repo</a><br>
<br>
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.<br>
<br>
Cheers,<br><font color="#888888">
Simon<br>
</font></blockquote></div><br></div></div>