git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: "W. Trevor King" <wking@tremily.us>, Git <git@vger.kernel.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Heiko Voigt <hvoigt@hvoigt.net>,
	Johan Herland <johan@herland.net>
Subject: Re: [RFC] submodule: change submodule.<name>.branch default from master to HEAD
Date: Mon, 31 Mar 2014 21:35:07 +0200	[thread overview]
Message-ID: <5339C36B.5020502@web.de> (raw)
In-Reply-To: <c66d89d854407469b6fd223213a09e5d60eeec0a.1395977055.git.wking@tremily.us>

Am 28.03.2014 04:36, schrieb W. Trevor King:
> gitmodule(5) mentioned 'master' as the default remote branch, but
> folks using checkout-style updates are unlikely to care which upstream
> branch their commit comes from (they only care that the clone fetches
> that commit).  If they haven't set submodule.<name>.branch, it makes
> more sense to mirror 'git clone' and use the subproject's HEAD than to
> default to 'master' (which may not even exist).
> 
> After the initial clone, subsequent updates may be local or remote.
> Local updates (integrating gitlink changes) have no need to fetch a
> specific remote branch, and get along just fine without
> submodule.<name>.branch.  Remote updates do need a remote branch, but
> HEAD works as well here as it did for the initial clone.
> 
> Reported-by: Johan Herland <johan@herland.net>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> This still needs tests, but it gets through the following fine:
> 
>   rm -rf superproject subproject &&
>   mkdir subproject &&
>   (cd subproject &&
>    git init &&
>    echo 'Subproject' > README &&
>    git add README &&
>    git commit -m 'Subproject commit' &&
>    git branch -m master next
>   ) &&
>   mkdir superproject &&
>   (cd superproject &&
>    git init &&
>    git submodule add ../subproject submod &&
>    git commit -am 'Add submod'
>   )
>   (cd subproject &&
>    echo 'work work work' >> README &&
>    git commit -am 'Subproject commit 2'
>   ) &&
>   (cd superproject &&
>    git submodule update --remote &&
>    git commit -am 'Add submod'
>   )
> 
> 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?

> Cheers,
> Trevor
> 
>  Documentation/git-submodule.txt |  2 +-
>  Documentation/gitmodules.txt    |  5 +++--
>  git-submodule.sh                | 11 ++++++++---
>  3 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index 46c1eeb..c485a17 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -284,7 +284,7 @@ OPTIONS
>  	the superproject's recorded SHA-1 to update the submodule, use the
>  	status of the submodule's remote-tracking branch.  The remote used
>  	is branch's remote (`branch.<name>.remote`), defaulting to `origin`.
> -	The remote branch used defaults to `master`, but the branch name may
> +	The remote branch used defaults to `HEAD`, but the branch name may
>  	be overridden by setting the `submodule.<name>.branch` option in
>  	either `.gitmodules` or `.git/config` (with `.git/config` taking
>  	precedence).
> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
> index f539e3f..1aecce9 100644
> --- a/Documentation/gitmodules.txt
> +++ b/Documentation/gitmodules.txt
> @@ -53,8 +53,9 @@ submodule.<name>.update::
>  
>  submodule.<name>.branch::
>  	A remote branch name for tracking updates in the upstream submodule.
> -	If the option is not specified, it defaults to 'master'.  See the
> -	`--remote` documentation in linkgit:git-submodule[1] for details.
> +	If the option is not specified, it defaults to the subproject's
> +	HEAD.  See the `--remote` documentation in linkgit:git-submodule[1]
> +	for details.
>  +
>  This branch name is also used for the local branch created by
>  non-checkout cloning updates.  See the `update` documentation in
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 6135cfa..5f08e6c 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -819,8 +819,8 @@ cmd_update()
>  		name=$(module_name "$sm_path") || exit
>  		url=$(git config submodule."$name".url)
>  		config_branch=$(get_submodule_config "$name" branch)
> -		branch="${config_branch:-master}"
> -		local_branch="$branch"
> +		branch="${config_branch:-HEAD}"
> +		local_branch="$config_branch"
>  		if ! test -z "$update"
>  		then
>  			update_module=$update
> @@ -860,7 +860,12 @@ Maybe you want to use 'update --init'?")"
>  
>  		if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
>  		then
> -			start_point="origin/${branch}"
> +			if test -n "$config_branch"
> +			then
> +				start_point="origin/$branch"
> +			else
> +				start_point=""
> +			fi
>  			module_clone "$sm_path" "$name" "$url" "$reference" "$depth" "$start_point" "$local_branch" || exit
>  			cloned_modules="$cloned_modules;$name"
>  			subsha1=
> 

  parent reply	other threads:[~2014-03-31 19:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27 14:21 Possible regression in master? (submodules without a "master" branch) Johan Herland
2014-03-27 15:52 ` W. Trevor King
2014-03-27 15:57   ` W. Trevor King
2014-03-27 17:23   ` Jens Lehmann
2014-03-27 18:30     ` Junio C Hamano
2014-03-27 22:55       ` Jens Lehmann
2014-03-27 23:27         ` Johan Herland
2014-03-28  2:33         ` W. Trevor King
2014-03-27 17:16 ` Junio C Hamano
2014-03-27 17:31   ` Jens Lehmann
2014-03-27 18:54     ` W. Trevor King
2014-03-27 19:39       ` Junio C Hamano
2014-03-27 20:27         ` Heiko Voigt
2014-03-27 23:06           ` Jens Lehmann
2014-03-27 23:21           ` Johan Herland
2014-03-28  3:05             ` W. Trevor King
2014-03-28  3:36               ` [RFC] submodule: change submodule.<name>.branch default from master to HEAD W. Trevor King
2014-03-28  3:43                 ` Eric Sunshine
2014-03-28  3:52                   ` W. Trevor King
2014-03-28  3:58                     ` W. Trevor King
2014-03-28 16:57                       ` Jens Lehmann
2014-03-28 17:10                         ` W. Trevor King
2014-03-31 19:31                           ` Jens Lehmann
2014-03-28 17:28                         ` Junio C Hamano
2014-03-31 19:35                 ` Jens Lehmann [this message]
2014-03-31 20:38                   ` W. Trevor King
2014-03-31 20:45                   ` Junio C Hamano
2014-03-27 21:01         ` submodule.<path>.branch vs. submodule.<name>.branch (was: Possible regression in master? (submodules without a "master" branch) W. Trevor King
2014-03-27 21:37           ` submodule.<path>.branch vs. submodule.<name>.branch Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5339C36B.5020502@web.de \
    --to=jens.lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hvoigt@hvoigt.net \
    --cc=johan@herland.net \
    --cc=wking@tremily.us \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).