RFC: migrating to git
rl at cse.unsw.edu.au
Thu Jan 13 00:20:25 CET 2011
On 12/01/2011, at 22:22, Iavor Diatchki wrote:
> 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.
Thank you so much for the explanation. Sadly, I'm still confused. Are you saying that "submodule update" is the wrong thing to do if I have changes in some of the submodules?
> 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.
How would we get the current functionality of darcs-all pull? Is it even possible?
Suppose I want to hack on GHC and base (base is a submodule of GHC). For this, I want to:
- pull the latest patches to both GHC and base
- write code
- record my patches in both GHC and base
- pull again to get whatever patches have been pushed while I was hacking
- push my patches to both GHC and base
Which commands would accomplish this?
The git docs still don't make any sense to me. FWIW, I'd be very wary of using any features that are so badly documented. Or programs, for that matter.
More information about the Glasgow-haskell-users