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 c
