Francesco Pretto writes:
> 2014/1/6 Heiko Voigt <hvoigt@xxxxxxxxxx>:
>> Could you describe something like this for your workflow? A complete
>> change lifecycle when a developer works, as you call it, "actively" in a
>> submodule?
>>
>
> I'm really sorry, I thought this was already clear from the first
> patch iteration. I will go more in depth:
While I have some trouble understanding all the details of Francesco's
description, I find the idea of "attaching submodules to branches" very
useful. I think I could well use that to simplify my merging grunt work
for GNU Emacs (which, in case you're wondering, is probably switching to
git as its VCS). I don't mean to hijack this thread, and I guess my use
case is a bit different than what Francesco has in mind; still, I think
it is similar enough that my use case could help in talking about the
details of his patch; if not, please feel free to ignore it.
GNU Emacs ships with some pretty large packages, namely Gnus, Org and
CEDET, which are also available as "stand-alone" versions for manual
installation, and their development happens in separate upstream
repositories. Since I'm a CEDET developer, I'll use it as an example in
the following.
First off, it is important to note that merges are always
bi-directional: not only is new CEDET code pulled into Emacs, but Emacs
developers also change things which have to be merged back upstream. So
far, merging between the two repositories was done manually by me, which
is error-prone (and boring). I think that by pulling in CEDET directly
as a submodule, this merging could be made easier. Most importantly, my
hope is that more people than me could do it. :-)
Here's how I would like this to work; first the CEDET -> Emacs part,
which is rather straight-forward:
- The CEDET repository has two branches: 'master' and 'stable'.
- The Emacs repository imports CEDET's 'stable' branch as a submodule.
- CEDET's main development happens in 'master', and the CEDET developers
are responsible for merging stable code to 'stable'. They will then
make a new commit for the submodule in Emacs accordingly.
The Emacs -> CEDET part is more hairy. Most of the time, the fixes
happening in the Emacs repository for CEDET are very small and/or
trivial and can usually be considered "always stable": fixes for
spelling, compiler warnings, or small refactorings like renames,
etc. This kind of "merging back to CEDET upstream" should hence be as
easy as possible for Emacs developers:
- When an Emacs developer changes something in the CEDET submodule, the
changes they commit should by default automatically land in CEDET's
'stable' branch. That means that when they enter the submodule, they
should be in the branch 'stable' instead of being detached, and a push
should update the 'stable' branch in CEDET accordingly. The submodule
must then be committed as well.
- It is then up to the CEDET developers to merge these changes into the
'master' branch of the CEDET repo.
I know that the "correct" workflow would be to always use feature
branches, but it'd be nice if that could be avoided if one so chooses.
A little picture in the hope that it makes things clearer:
+-----------+
| master | <--
+-------+ +-----------+ | Merges to/from master
| CEDET | | done only by CEDET developers
+-------+ |
+-----------+ |
| stable | <-- <--------
+-----------+ |
|
|
| Any Emacs developer
| can push and commit
| submodule
+--------+ +----------------------+ |
| Emacs | -- | lisp/cedet submodule | <-
+--------+ +----------------------+
AFAICS the main problem with this approach is that one always has to
think of committing the new SHA1 of the submodule. If I understand
Francesco correctly, he wants to eliminate the need for that by simply
always taking the head of the attached branch. I also think that would
be a nice feature, since in the above drawing, the lisp/cedet submodule
should always follow the 'stable' branch in CEDET upstream. 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?
-David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html