Jens Lehmann <Jens.Lehmann@xxxxxx> writes:
> This is a follow-up to gmane thread 200564 about teaching "git
> submodule" the "rm" command. It has the intention to only having
> to add a small amount of new code to the submodule script while
> handling the heavy lifting in core git.
>
> With this series I also intend to make submodule handling a bit
> easier for users by teaching "git rm" to remove the submodule
> section from the .gitmodules file, no matter if the submodule is
> populated or not. Not being able to do that because the section
> is not found there or the .gitmodules file is already deleted
> will only issue a warning (with the intent to make the user aware
> that "git rm" would do that for him in case he did that himself).
I wouldn't claim that I have thought things through yet, but in
general my instinct tells me that it is a bad idea to try pushing
down "submodule management" related bits to the core.
Let me think aloud about removing a directory, in a checkout of a
superproject, that has a submodule checkout. There are at least two
majorly different reasons a user wants to do this:
(1) The project used to bind a submodule as a part of the
superproject there, but it no longer wants to do so (e.g. we
used to ship compiler toolchain as part of our embedded
appliance superproject, but from this release on, we expect
developers to install the toolchain on their own). We want to
remove the submodule directory, we want to remove the submodule
entry in the superproject's tree, and we want to remove the
submodule entry from .gitmodules file.
(2) One particular project participant has been working on one part
of the superproject, say "the documentation submodule", hence
"submodule init" was used for that submodule part to populate
it. Since the participant has done with the work, there is no
longer need to keep the submodule checkout (submodule uninit?),
and getting rid of it makes the working tree leaner and "git
pull" faster (as there is no longer need to fetch updated
history in the uninteresting submodule). We just want to
remove the contents of the submodule directory. We do want to
keep the index entry for the submodule in the superproject. We
do want to keep the .gitmodules intact.
This kind (1) of reorganization hopefully is rare (in other words,
you wouldn't drop a submodule today and turn around to add it again
tomorrow), done by one person and the result is propagated to all
other project participants. On the other hand, (2) can be done by
any and all participants of the project at any time.
Which audience should "git rm $path" serve? My gut feeling is that
the "project structure change" part that goes beyond the core
(e.g. what is in ".gitmodules") and should be a rare flag-day event
deserves a separate command, if only to make the user aware that the
user is invoking a heavy-weight (from the point-of-view of the
workflow) operation.
I am not convinced that "git rm $path" is a good interface for (2),
though. For one thing, you would need to keep an empty directory at
the submodule path for the purpose of (2), so it is not really "rm".
Perhaps "git submodule uninit" might be needed to support (2), in
addition to "git submodule rm" to support (1).
--
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