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,
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

Reply via email to