On Tue, Nov 27, 2012 at 09:42:05PM -0500, W. Trevor King wrote: > On Wed, Nov 28, 2012 at 12:28:58AM +0100, Heiko Voigt wrote: > > https://github.com/hvoigt/git/commits/hv/floating_submodules_draft > > I looked over this before, but maybe not thoroughly enough ;). Heiko pointed out that I likely hadn't looked at this branch at all, which is true. I'd confused it with his earlier: On Fri, Nov 09, 2012 at 05:29:27PM +0100, Heiko Voigt wrote: > https://github.com/hvoigt/git/commits/hv/floating_submodules but the new floating_submodules_draft branch adds Heiko's function reorganization and floating submodule pull (with 'update --branch') on top of my v4 commits (instead of my branch-checkout with 'update --branch'). > This looks fine, but my current --branch implementation (which doesn't > pull) is only a thin branch-checkout layer on top of the standard > `update` functionality. I'm still unsure if built-in pulls are worth > the configuration trouble. I'll sleep on it. Maybe I'll feel better > about them tomorrow ;). I do feel better about them today. To get a better feel for how people see this going forward, here is a summary of proposals to date: v1. Record submodule..branch with 'submodule add --branch …', leave interpretation up to the user. Feedback (paraphrased): Phil Hord: that clobbers a configure option used by Gerritt and possibly others, rename to --record-branch. Maybe we should export submodule..* as $submodule_* in 'foreach'? Nahor: what about corner cases (e.g. upstream renames branches)? Jens Lehmann: if you record it, people will expect Git to use it. What about automatic pulls & commits? v2. Add --record instead of using --branch to address Phil's v1 comment. Feedback (paraphrased): Jens Lehmann: this is still a tiny optimization over using 'git config'. People still use this option in different ways. Shawn Pearce: the Gerrit use is basically the same as Ævar's, but Gerrit has special handling for '.'. Jeff King: if we set up submodule..branch, we should either use it in Git, or make it very clear that we do not use it. If we use Phil's $submodule_* export, we should clear the variables for recursive submodules. v3. Renamed Added $submodule_* export to v2. Give an example of Ævar's pull workflow when explaining that Git does not use the value internally. Feedback (paraphrased): Heiko Voigt: what about automatic pulls & commits? You should allow .git/config overrides of the .gitmodules settings. if we set up submodule..branch, we should use it in Git. How does the submodule know which remote branch to track? Junio's proposed 'diff' changes may hide $sha1 information. Junio C Hamano: if we set up submodule..branch, we should use it in Git. Use something more specific than --record. Update 'git diff [$path]' and friends in the superproject compares the HEAD of the checkout of the submodule at $path with the tip of the branch named by submodule.$name.branch in .gitmodules of the superproject, instead of the commit that is recorded in the index of the superproject. Sascha Cunz: you can use 'git shortlog $OLD_SHA1..$NEW_SHA1' for the automatic commit message. Trevor King: actually, Ævar's update command only specifies the local branch name. The remote is recorded for that branch in .git/modules//config. v4. Rename --record to --local-branch. Remove $submodule_* export. Add .git/config overrides for submodule..branch. Add 'submodule update --branch' to check out $sha1 as submodule..branch. Feedback (paraphrased): Heiko Voigt: who cares about the local branch name? You should be pulling origin/$branch, but still using .git/modules//config to record the tracked branch. You should also use 'submodule add --branch[=branch]' instead of '--local-branch'. You should pull the 'update --branch' functionality out into a sub-function like 'handle_tracked_branch_update'. Jens Lehmann: .git/config overrides are nice, but they should be optional. Trevor King: floating branches are following the submodule's remote, while 'update --rebase/--merge' are following the superproject's recorded $sha1. Bundling remote-following and superproject-following in the same command may be confusing. Here's what I think we need in v5: * Jens' optional .git/config overrides. * Return --local-branch handling to a side effect of --branch (as in v1). * A new 'submodule pull' for tracking the submodule's remote, which is pulling --ff-only origin/$branch into a whatever state the submodule is currently in. If any changes were made to submodule $shas, optionally commit them with a shortlog-generated commit message. * Remove my current 'submodule update --branch' functionality. Thoughs? Do we need any more information for an automatic pull, or is $ git pull --ff-only origin/$branch on a headless checkout sufficient? 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