On 18/03/2014 18:17, Johan Tibell wrote:
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.
# Step 1:
cd ~/src/ghc/libraries/base
# edit some_file
git add some_file
git commit -m "Commit to base repo"
git push # push update to base to git.haskell.org <http://git.haskell.org>
I believe this doesn't work, because the normal state for a submodule is
"detached HEAD", so you can't commit to it because it isn't on a branch.
You have to first "get checkout master", or "git checkout -b mybranch
master".
# Step 2
cd ~/src/ghc
git add libraries/base
git commit -m "Have GHC use the new base version"
git push # push update to ghc to git.haskell.org <http://git.haskell.org>
Failure modes include:
* 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.
* 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.
How could sync-all help us:
* sync-all push could push all repos, preventing failure case 2 above.
The second interesting workflow involving pulling new changes. This is
what the raw (i.e. no sync-all) workflow will look like:
cd ~/src/ghc
git pull
git submodule update
Failure modes include:
* 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.
The other failure mode is that the submodule contains local changes,
that just got overwritten by the "git submodule update". Perhaps git is
better about telling you when this is about to happen and/or failing in
submodule update now? What about when the submodule is on a branch?
Cheers,
Simon
How could sync-all help us:
* sync-all pull could always run `submodule update`.
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.
I think if base was folded into ghc.git very few people would have to
deal with submodules.
On Tue, Mar 18, 2014 at 11:58 AM, Herbert Valerio Riedel <[email protected]
<mailto:[email protected]>> wrote:
Hello *,
I've put in place a new server-side validation hook a few days ago, and
since nobody seemed to have complained yet, I assume it didn't have any
adverse effects so far :-)
It will only be triggered when Git submodule references are touched by a
commit; you can find some preliminary (but incomplete) documentation and
a sample session triggering validation-failure on purpose at
https://ghc.haskell.org/trac/ghc/ticket/8251#comment:4
(this will be turned into a proper wiki-page once #8251 is completed;
there's some minor details wrt some corner cases that still need to be
looked at)
So, this mostly addresses the server-side requirements for migrating to
a proper git-submodule set-up for ghc.git;
The next steps, however, include taking care of the client-side
work-flow
for working with a fully "submoduled" ghc.git setup. Personally, I'm
quite comfortable using direct git commands to manage such a construct,
but I'm well aware not everyone is (as previous discussions here have
shown). Also, as my time is rather limited, I'd like to ask interested
parties to join in and help formulate the future client-side
work-flow[1]
and/or update (or rewrite) the 'sync-all' to provide a seamless or at
least smooth transition for those GHC devs who want to keep using
"sync-all" instead of using direct Git commands.
[1]: There's some difference in how tracked upstream packages and
GHC-HQ owned sub-repos are to be handled workflow-wise, to avoid
ending up with a noisy ghc.git history.
For instance, having ghc.git with submodules is not the same as
having a huge monolithic ghc.git repository with all subrepos
embedded. specifically, it might not be sensible to propagate
*every* single subrepo-commit as a separate ghc.git submod-ref
update, but rather in logical batches (N.B.: using submodules
gives the additional ability to git bisect within subrepos
instead
of having to bisect always only at top-level). This is one
example
of things to discuss/consider when designing the new work-flow.
Cheers,
hvr
_______________________________________________
ghc-devs mailing list
[email protected] <mailto:[email protected]>
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
