<div dir="ltr"><div class="gmail_extra">Lets give some example workflows for working with submodules. Here's what I think a raw (i.e. no sync-all) update to base will look like. Please correct me if I'm wrong.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"># Step 1:</div><div class="gmail_extra">cd ~/src/ghc/libraries/base<br></div><div class="gmail_extra"># edit some_file</div><div class="gmail_extra">git add some_file</div>
<div class="gmail_extra">git commit -m "Commit to base repo"</div><div class="gmail_extra">git push # push update to base to <a href="http://git.haskell.org">git.haskell.org</a></div><div class="gmail_extra"><br>
</div><div class="gmail_extra"># Step 2</div><div class="gmail_extra">cd ~/src/ghc</div><div class="gmail_extra">git add libraries/base</div><div class="gmail_extra">git commit -m "Have GHC use the new base version"</div>
<div class="gmail_extra">git push # push update to ghc to <a href="http://git.haskell.org">git.haskell.org</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">Failure modes include:</div><div class="gmail_extra">
<br></div><div class="gmail_extra"> * Forgetting step 2: the ghc repo will point to a slightly older base next time someone checks it out. Fixing things when in this state: just perform step 2.</div><div class="gmail_extra">
* Forgetting `git push` in step 1. the ghc repo will point to a base commit that doesn't exist (except on some developers machine). Fixing things when in this state: the developer who forgot to `git push` in step 1 needs to do that.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">How could sync-all help us:</div><div class="gmail_extra"><br></div><div class="gmail_extra"> * sync-all push could push all repos, preventing failure case 2 above.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The second interesting workflow involving pulling new changes. This is what the raw (i.e. no sync-all) workflow will look like:</div><div class="gmail_extra"><br>
</div><div class="gmail_extra">cd ~/src/ghc</div><div class="gmail_extra">git pull</div><div class="gmail_extra">git submodule update</div><div class="gmail_extra"><br></div><div class="gmail_extra">Failure modes include:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"> * Forgetting the `submodule update` and then doing e.g. `git commit -am "some compile commit"`, reverting the pointer to e.g. base to whatever older version the developer was using. No commits are lost (nothing changes in the base repo), but the ghc repo will point to an older commit.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">How could sync-all help us:<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"> * sync-all pull could always run `submodule update`.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">The server-side check that Herbert added will make sure that the failure mode cannot happen, as you explicitly have to say in the commit message that you updated a submodule.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">I think if base was folded into ghc.git very few people would have to deal with submodules.<br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 11:58 AM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello *,<br>
<br>
I've put in place a new server-side validation hook a few days ago, and<br>
since nobody seemed to have complained yet, I assume it didn't have any<br>
adverse effects so far :-)<br>
<br>
It will only be triggered when Git submodule references are touched by a<br>
commit; you can find some preliminary (but incomplete) documentation and<br>
a sample session triggering validation-failure on purpose at<br>
<br>
<a href="https://ghc.haskell.org/trac/ghc/ticket/8251#comment:4" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/8251#comment:4</a><br>
<br>
(this will be turned into a proper wiki-page once #8251 is completed;<br>
there's some minor details wrt some corner cases that still need to be<br>
looked at)<br>
<br>
So, this mostly addresses the server-side requirements for migrating to<br>
a proper git-submodule set-up for ghc.git;<br>
<br>
The next steps, however, include taking care of the client-side work-flow<br>
for working with a fully "submoduled" ghc.git setup. Personally, I'm<br>
quite comfortable using direct git commands to manage such a construct,<br>
but I'm well aware not everyone is (as previous discussions here have<br>
shown). Also, as my time is rather limited, I'd like to ask interested<br>
parties to join in and help formulate the future client-side work-flow[1]<br>
and/or update (or rewrite) the 'sync-all' to provide a seamless or at<br>
least smooth transition for those GHC devs who want to keep using<br>
"sync-all" instead of using direct Git commands.<br>
<br>
<br>
[1]: There's some difference in how tracked upstream packages and<br>
GHC-HQ owned sub-repos are to be handled workflow-wise, to avoid<br>
ending up with a noisy ghc.git history.<br>
<br>
For instance, having ghc.git with submodules is not the same as<br>
having a huge monolithic ghc.git repository with all subrepos<br>
embedded. specifically, it might not be sensible to propagate<br>
*every* single subrepo-commit as a separate ghc.git submod-ref<br>
update, but rather in logical batches (N.B.: using submodules<br>
gives the additional ability to git bisect within subrepos instead<br>
of having to bisect always only at top-level). This is one example<br>
of things to discuss/consider when designing the new work-flow.<br>
<br>
Cheers,<br>
hvr<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br></div></div>