On Mon, Mar 31, 2014 at 09:35:07PM +0200, Jens Lehmann wrote: > Am 28.03.2014 04:36, schrieb W. Trevor King: > > The main drawback to this approach is that we're changing a default, > > but I agree with John's: > > > > On Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote: > >> I expect in most cases where "origin/master" happens to be the > >> Right Answer, using the submodule's upstream's HEAD will yield > >> the same result. > > > > so the default-change may not be particularly intrusive. > > I'd prefer a solution that doesn't change any defaults for the > checkout use case (again). Maybe it is a better route to revert > this series, then add tests describing the current behavior for > checkout submodules as a next step before adding the branch mode > for rebase and merge users again?
The change in defaults should only adversely effect users who: * don't configure submodule.<name>.branch, * use --remote updates, * expect them to pull the master branch of the submodule's upstream, and * have an upstream whose HEAD doesn't point at master. Since 23d25e4 (submodule: explicit local branch creation in module_clone, 2014-01-26), we adversely effects users (regardless of update strategy) who: * don't configure submodule.<name>.branch, and * update-clone from a submodule upstream that doesn't have a master branch. But with this patch we'll fix that. Before 23d25e4, we adversly affected users who: * used non-checkout update strategies, and * wanted an attached HEAD after update-clones. All of these were easy to work around, with either: $ git config submodule.$name.branch $branch or: $ cd $submod $ git checkout $branch I'm fine reverting 23d25e4 if we want to kick it around some more, but I have trouble imagining a future UI that works for both: * users that want --remote to pull master even though upstream's HEAD points elsewhere, and * users that want --remote to pull HEAD because upstream doesn't have a master branch, if neither of those users are willing to configure an explicit submodule.<name>.branch. Cheers, 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
signature.asc
Description: OpenPGP digital signature
