2014/1/5 Heiko Voigt <hvo...@hvoigt.net>: > Could you please extend the description of your use-case so we can > understand your goal better? >
Maybe I found better words to explain you my goal: the current git submodule use-case threats the submodule as a project independent dependency. My use case threats the submodule as part of the superproject repository. It could be easier to say that in this way submodules would behave very similarly to "svn:externals", something that is actually missing in git. My goal is obtain this without altering git behavior for the existing use case. > - In which situations does the developer or maintainer switch between > your attached/detached mode? As I told you in the other answer this is voluntary done by the developer, as he prefers. I came to the conclusion that the "--attach|--detach" switches for the "update" command are not that useful and can be removed. It's still possible to obtain the switch between detached/attached very easily in this way: # Attach submodule $ git config submodule.<name>.attached "true" $ git submodule update # Detach submodule $ git config submodule.<name>.attached "false" $ git submodule update # Unset property in both ".gitmodules" and ".git/config" means -> do nothing $ git config --unset submodule.<name>.attached $ git submodule update Also my "submodule.<name>.attached" property at the moment behaves like "submodule.<name>.update": it is copied in ".git/config" by "git submodule init". This is probably a mistake: the overridden value should be stored in ".git/config" only at the developer will, so the maintainer has still a chance to modify it in ".gitmodules" and propagate the behavior. I would send an updated patch but at this point I prefer to wait for a full review. Thank you, Francesco -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
