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


  $ 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


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

Reply via email to