On Fri, Nov 23, 2012 at 04:55:21PM +0100, Heiko Voigt wrote:
> On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote:
> > "W. Trevor King" <wking@tremily.us> writes:
> > 
> > > The superproject gitlink should only be updated after
> > >
> > >   $ git submodule update --pull
> > >
> > > A plain
> > >
> > >   $ git submodule update
> > >
> > > would still checkout the previously-recorded SHA, not the new upstream
> > > tip.
> > 
> > Hrm, doesn't it make the "float at the tip of a branch" mode
> > useless, though?
> 
> How about having a branch config option and reusing our
> submodule.$name.update option for specifying whether the user wants to
> always float to the tip of the branch?

I'm adding "update --pull" as one of the update options in v4, which I
am writing up as we speak ;).

> 1. If submodule.$name.update is pull it would checkout the specified tip.

and pull from the submodule's upstream.  This doesn't need the
recorded $sha1, so I may have to rework the current

  if (clear_local_git_env; cd "$sm_path" && $command "$sha1")

> 2. If submodule.$name.update is checkout or none it would do the usual
>    thing and you need to specify --pull to get the tip.

Exactly.

> So currently I am more on the "have an automatically generated
> commit message" side. Its in a similar corner like merge commits, that
> are also generated, for me. We could have it as the default and a
> --no-commit option (like merge) for people that want to stage submodules
> individually.

This sounds reasonable, but I'd like to postpone message-generation
sugar until we get the basic functionality ironed out.

On Fri, Nov 23, 2012 at 05:03:01PM +0100, Heiko Voigt wrote:
> On Tue, Nov 20, 2012 at 07:19:12AM -0500, W. Trevor King wrote:
> > The benefit is that Ævar's
> > 
> >   $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
> > 
> > becomes
> > 
> >   $ git submodule update --pull
> 
> There is an important question still unanswered here for me: How does
> the submodule get the configuration what the local branch tracks on the
> remote side?

A good point ;).  I'm actaully using submodule.<name>.branch to store
the submodule's local branch name.  The remote branch name for the
pull is implicit, and defaults to something setup according to
branch.autosetupmerge (I think).  If you want to get more complicated
than this, we'll probably have to add submodule.<name>.branch and
submodule.<name>.remote sections to augment the
submodule.<name>.branch setting.  I'm not sure this is worth it.

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy