On Mon, Jan 06, 2014 at 12:22:23AM +0100, Francesco Pretto wrote: > 2014/1/5 Heiko Voigt <hvoigt@xxxxxxxxxx>: > > 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. I am not so sure. svn:externals was IMO a hack in SVN to bind projects together. It does not record the revision and so has nothing to do with version control. If you simply want to always checkout the development tip of some project you could do something like this: git submodule foreach 'git fetch && git checkout origin/master' The demand for this 'missing feature' which we call the 'floating submodules' model has been around for some time but until now we could convince people that its not a feature but you are actually loosing history information. The workflow could always be changed to allow recording revisions. Which is why you use git in the first place right? If you discard revisions for submodules tracking down regression bugs can become a big problem or completely impossible. Try using git bisect on such a history. > > - 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. Could you tell me a typical reason? > 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. Lets first discuss and figure out what is the real missing feature here and what should be implemented before working further on the code. Cheers Heiko -- 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