On Mon, Jan 06, 2014 at 08:21:24PM +0100, David Engster wrote: > +-----------+ > | master | <-- > +-------+ +-----------+ | Merges to/from master > | CEDET | | done only by CEDET developers > +-------+ | > +-----------+ | > | stable | <-- <-------- > +-----------+ | > | > | > | Any Emacs developer > | can push and commit > | submodule > +--------+ +----------------------+ | > | Emacs | -- | lisp/cedet submodule | <- > +--------+ +----------------------+ This looks reasonable, and except for the detached-HEAD after the initial update-clone, I think Git already supports everything you need. If you set submodule.cedet.update to 'rebase' (or 'merge') you can easily integrate your local master changes with cedet/master (e.g. if a CEDET dev updates cedet/master before the Emacs dev has a chance to push their fix). With the non-checkout update mode, you'll also stay on your checked-out master branch during 'submodule update' calls. > AFAICS the main problem with this approach is that one always has to > think of committing the new SHA1 of the submodule. > … > However, as Heiko notes, the history must be preserved to be able to > go back to earlier revisions, so there must be some kind of commit > for the submodule when 'stable' changes; maybe that could be > automated somehow? If an Emacs dev in the submodule makes the CEDET change, you could use a post-commit hook (in the CEDET submodule) to also commit the change to the Emacs superproject). However, commiting only the submodule bump may not be what you want. Maybe there are other superproject changes that should be committed alongside the submodule bump. Maybe there is stuff in the superprojects's staging area that should *not* be committed alongside the submodule bump. This ambiguity makes it tricky for Git to automatically do “the right thing”. If cedet/master is updated independently by the CEDET devs, there's no way for the local Emacs repo to know about the change, so it's impossible to automatically update Emacs (without polling for CEDET updates or some other transgression ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Attachment:
signature.asc
Description: OpenPGP digital signature