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" <wk...@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
Description: OpenPGP digital signature