On Tue, Oct 27, 2015 at 12:56 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > Which seems a bit error prone as you could forget to update the submodules > and build incorrect rpms from them, or am I missing something? For my case I'm not building the rpms directly after merging in the fixes done in the octopus branch, so I don't care much about the state of the submodules after the merge since I know that the octopus branch does not modify any submodules. The rpms are built later on, possibly on another machine where the submodules are updated w.r.t to each branch in a release commit. > I understand why you don't need to update the submodules every time, but > would it hurt your workflow if they did (but don't get me wrong, that will > always be configurable). I'd say it depends - for the times when all I want to do is work on plain files in the superproject (on an octopus branch for example) I don't want git to automatically update the submodules everytime I switch branches - it would hurt my productivity as there will be more disk activities due to files being checked out unnecessarily for updating the submodules. The submodule states are not committed that often into the superproject, they are done normally when we're cutting a new release. During day-to-day development each developer runs a script that pulls in the latest commits for "hot" submodules. git not updating the submodule state automatically is actually a convenient for my particular use case here. nazri -- 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