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.<name>.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.<name>.* 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.<name>.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.<name>.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.<name>.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/<name>/config. v4. Rename --record to --local-branch. Remove $submodule_* export. Add .git/config overrides for submodule.<name>.branch. Add 'submodule update --branch' to check out $sha1 as submodule.<name>.branch. Feedback (paraphrased): Heiko Voigt: who cares about the local branch name? You should be pulling origin/$branch, but still using .git/modules/<name>/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
Attachment:
signature.asc
Description: OpenPGP digital signature