On Fri, Nov 23, 2012 at 11:23:29AM -0500, W. Trevor King wrote:
> 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 ;).

On second thought, this does not seem to be a good idea.  The current
fancy update styles (--rebase, --merge) are both for cases where you
have local commits in the submodule and are trying to incorporate new
gitlinks from an updated superproject into the submodule's checked out
branch:

  superproject $ cd submod
  superproject $ git checkout next
  submod $ …hack hack hack…
  submod $ git commit …
  submod $ cd ..
  …upstream superproject changes…
  superproject $ git pull
  …updated SHA1 for submod gitlink…
  superproject $ git submodule update --merge
  …merge superproject's gitlink SHA1 into local submod branch…

My submodule.<name>.branch option gives a local branch to
check out:

  …upstream submod changes…
  superproject $ git cd ssubmodule update --pull
  …fetch upstream submod changes and ff-merge into local submodule.<name>.branch…

This seems suitably distinct that bundling it with the other update
options will just add confusion.

So, let's rethink this approach.  I'm trying to pull the upstream
version of my local submod branch.  The difficulties with this are:

1. Checking out a local branch (from the default detached state)
   to do something on it requires an ungainly:

     $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && …'

2. The remote pulling behavior is configured in
   .git/modules/<name>/config, which is not tracked in the repository
   itself.

I'm ok with forcing local users to handle 2 manually (or implicitly),
but 1 is crazy.  Addin submodule.<name>.branch explicitly to
.gitmodules is a step towards fixing 1, but submod pull doesn't match
an existing submodules-implemented workflow.  Perhaps a better choice
would be to borrow the implicit-local-checkout behaviour used by
--rebase and --merge.  We could add

  $ git submodule update --branch

to checkout the gitlinked SHA1 as submodule.<name>.branch in each of
the submodules, leaving the submodules on the .gitmodules-configured
branch.  Effectively (for each submodule):

  $ git branch -f $branch $sha1
  $ git checkout $branch

Then I could use

  $ git submodule foreach 'git pull'

to update my submodule tracking branches (without further "git
submodule" restructuring).

This would help everyone that doesn't like the detached head state (me
and --rebase/--merge users).  I could avoid implementing "update
--pull", and all of the difficulty in configuring upstream merge
choices (2) would be punted to the user making local edits in
.git/modules/<name>/config.

Trevor

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