Re: Why do git submodules require manual checkouts and commits?

["Avery Pennarun" <apenwarr@gmail.com>]

On 5/16/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>  On Fri, 16 May 2008, Avery Pennarun wrote:
>  > But with submodules, that common case looks more
>  > like this:
>  >    cd sub
>  >    git checkout -b manual_branchname_because_there_was_no_default
>  >    git commit -a
>  >    git push etc.
>  >    cd ..
>  >    git commit -a
>  >    git push etc.
>
> Funny, for me it looks completely different:
>
>  $ cd sub
>  # work, work, work
>  # from time to time commit
>  # from time to time rebase -i to clean up some things
>  # test, test, test
>  # sometimes push
>
>  And then, every once in a while, it is
>
>  $ cd ..
>  $ git add submodule
>  $ git commit -s submodule
>  $ git push

Indeed.  I think you and I use submodules for very different purposes.
 The important case for me is that I often add a function to a library
(submodule), then *immediately* move on to use that function in an
application (supermodule).  When I commit the new submodule gitlink,
there are almost always other source code changes in the supermodule
at the same time.  And then I want to share the new application with
my co-workers shortly thereafter, often several times per day.

It looks like your own work on submodules tends to be quite isolated
from the supermodule, which would make sense if you use submodules for
(say) bundling a bunch of separate applications together.

>  > That's *really* tedious, and the number of commands multiplies when you
>  > have more than one submodule going at once.
>
> But hey, if you find that tedious, why did I not see a patch from you yet,
>  implementing "git submodule commit-n-push"?

Well, I think someone already submitted some "git submodule recursive" stuff.

I don't mean to complain.  I think the existing git-submodule code
gives all the raw materials necessary to solve all my
submodule-related problems, whatever those problems may be.  I'd much
rather have tedious-but-flexible instead of quick-but-inflexible.
However, having such powerful tools means it takes longer to figure
out how to use them most effectively.

Don't worry, I'll be the first to submit an all-singing all-dancing
shell script as soon as I figure out what that looks like.  Err,
unless someone else submits it first.  I guess that should cover all
my bases :)

(And now... I'm going to disappear for at least a week for vacation.  Bye!)

Have fun,

Avery